Проблемы с записью звонков никакой нет.
Если человек не хочет, чтобы его слова использовали против него — пусть их не произносит.
А уж если сказал — будь готов отвечать.
Боятся записи только лгуны и мошенники.
А если есть подозрения на подделку записи — вот тут и выручает запись Яровой или экспертиза.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Абсолютно так.
Это фиаско
Есть красное русское слово для этого случая — «очковтирательство». Кажется, оно как нельзя лучше подходит для иллюстрации смысла планирования в сторипоинтах.
Вы работаете в одиночку?
Отнюдь. «Мой» означает, что я использую эти критерии в работе. Вне зависимости мою или чужую работу планирую.
Критерии «известен-код, известно-что-делать, есть-все-требования» значительно точнее, чем «джун-мидл-сеньор» в вашем способе планирования. Вкупе с более точным инструментом измерения дают вообще фантастическую точность относительно спринтов через сторипоинты.
и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.
оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Вы говорите о создании продукта или о прикрытии зада перед начальством?
Мой спринт такой:
— если работал и помнишь код, где нужно поменять и знаешь как это поменять, то 0,5 часа
— если не работал с кодом, но понимаешь, что поменять нужно чуть — 1 час
— если понимаешь, что поменять чуть, но с кодом не работал, в архитектуру вникать нет смысла и нужно обсуждать с заказчиком нюансы — 2 часа
— создание новой фичи на знакомом коде без архитектурных изменений — 4 часа
— любые работы, вызывающие изменение бизнес-логики или архитектуры решения — 6 часов на старте, затем по итогам этих 6ти часов
— отсутствие точных требований к задаче — плюс 1 час к расчетному времени
— ввод в работу нового проекта (подготовка рабочего окружения, изучение архитектуры) — 3-4 часа в зависимости от стека
По этой сетке можно разложить любую задачу на подзадачи и вывести расчетное время готовности проекта.
Но это, конечно, если хватает знаний для декомпозиции. А если нет — берешь паузу и в свободное от работы время учишься там, где не хватает.
Продуктивный день разработчика 6 часов. За 20 лет работы не видел ни одного уникума, способного кодить 8 часов с перерывом на обед. Чай/кофе/перекуры легко съедают 2 часа рабочего времени. Да и санитарные нормы 45/15 в час не на пустом месте придуманы были.
Группа — это несколько объектов, объединенных одним или более общим признаком.
Команда — не голосовая — это группа разнообразных объектов, способная решать какую-либо задачу или выполнять работу с измеряемым параметром эффективности.
Группа определяется путём обобществления, команда подбирается путём детализации. Т.е. в группе важно делать упор на то, что людей объединяет. В команде же важно, чем один человек отличается от другого и как это укладывается в общее дело.
Для группы замена одного члена другим не принципиальна — всё равно в группе у всех одинаковый признак группы и группа при этом не перестает быть группой. В команде же замена одного члена другим практически невозможна. Выбытие участника команды останавливает всю команду. Подбор замены не всегда возможен.
Если разложить на столе детали редуктора — это будет группа запчастей. Общий признак — они предназначены для редуктора. На столе могут лежать несколько разобранных редукторов и это всё будет одна группа запчастей редуктора.
Но если собрать часть запчастей в редуктор — это уже будет команда, применительно к технике — узел, агрегат — в котором каждый член выполняет свою индивидуальную функцию, а вместе они передают крутящий момент от источника к получателю.
Лидам и менеджерам нужно помнить:
1) В туалет ходят с туалетной бумагой, а в душ с полотенцем; и не наоборот. Агил используют в поддержке продукта, ватерфол в разработке.
2) Если для планирования нужна консультация кодера/разработчика, то лид/менеджер — никто. У каждого своя работа, писать код и строить планы — это разные вселенные. Менеджеру сдать проект нужно как можно быстрее, а разработчик хочет сделать как можно надежнее. Каким хреном они могут вообще сами договориться? Цели разные.
3) Команда — это не группа. В группе может быть сколько угодно каких угодно человек. Но в команде каждый человек берет на себя часть от 5ти ролей. И ранжировать людей джун-мидл-сеньор в команде невозможно, т.к. у всех разные роли и за счет этого команда действует как единый механизм.
А в целом всем нам знакомо, что происходит, когда молодого необразованного амбициозного человека назначают начальником над соплеменниками. Коллеги, не расслабляйтесь, изучите матчасть по скрамам, агилам, ватерфолам и командам. И посылайте недоменеджеров и недолидов сразу, как услышите их «фирменный» сленг («фасилитация», например).
Человеку свойственно за англицизмами и подменой понятий скрывать недостаток знаний и навыков.
На месте работодателя я бы попросил удалить эту статью, чтобы не позорить компанию.
Коллеги! А не встречал ли кто пленочного фотоаппарата с цифровым дублёром?
Т.е. такого зверя, который одновременно открывает затвор и в тот же момент делает цифровой снимок для превью. Ну, чтобы моргунов можно было сразу переснять или получить представление об удачном кадре до того, как проявишь плёнку, в момент, когда еще можно что-то исправить.
И на волне позитива: можно будет сайты отправлять даже Почтой России!
Легко представить: звонок в дверь, на пороге почтальон такой «Вам пакет habr.com! Распишитесь»
То самое чувство, когда для существования Интернета сам Интернет и не нужен )
4. Уровень компьютерной грамотности большинства заказчиков ПО (руководителей или клиентов) ниже низкого. Из-за этого, их ТЗ выглядят как «нужно, чтобы программа делала это и то». Как именно, в каких случаях, как быстро — они не знают, список технических требований сформулировать не могут. По молодости такие проекты очень интересны — их делаешь по 2-3 раза, каждый раз уточняя и ликвидируя проблемы, возникающие при внедрении. Но к 35 годам после множества разработок уже на первых строках задачи клиента видишь, какие проблемы он огребёт в итоге. Разумеется, объясняешь, тогда либо проект сворачивают, либо тебя заворачивают. Проблема в том, что надоедает такая работа. Привлекает уже больше работать с профессионалами, которые знают, чего хотят и куда идут. А таких очень мало на пост-СССР территории.
Разве в этом случае вина за «фейковость» новости не будет сниматься с конечного пользователя (если он опубликовал сообщение в неизменном виде)?
По поводу фейка к пользователю претензий не будет.
В претензию станет «распространение недостоверной информации»
А по наказанию это столько же, как и создание фейковой новости
Честно говоря я не очень понимаю, как DNS over TLS или DNS over HTTPS поможет против подделки каким-то DNS-сервером записей.
Тут просто. Если DNS сервер будет работать по принципу HTTPS, то для получения надежного ответа, к нему нужно будет обращаться напрямую с использованием TLS. В этом случае ответ от сервера можно считать валидным, т.к. вероятность его подмены в пути очень мала.
Если TLSA записи передавать открытым текстом, то ничего не мешает на узле провайдера заменять данные своим сертификатом. Вкупе с возможностью организовать MiTM это вообще сводит к нулю идею HTTPS для сайтов.
На самом деле повальная автоматизация создаёт проблемы, решение которых откладывается «на потом»: растущие требования к квалификации сотрудников дают кадровый голод, повышается порог входа в отрасль для новичков и стажеров; освобождающиеся рабочие руки пополняют армию безработных и, соответственно, людей с малым достатком, что негативно сказывается на покупательской способности; снижается «гибкость» бизнеса — чтобы изменить политику компании, нужно провести большую подготовительную работу, переписать схемы автоматизации прежде, чем объявить о новой «фишке» на рынке.
Это тезисно. Если развернуть, объемный роман можно написать из этой темы.
Западные страны, пионеры автоматизации, на текущий момент решают проблему за счет восточных стран, вытягивая достойные кадры-самородки из РФ, Индии, Китая. Своих кадров у них нет и не может появиться, т.к. базы, на которой могут обучиться люди, у них практически нет — неавтоматизированных и недо-автоматизированных систем имеется в виду.
То, что случилось с бухгалтерами за последние 30 лет, ожидает и программистов через 5-10 лет. Пока зарплаты еще на уровне, но тренд на спад уже пошел, и реальной интересной работы становится всё меньше и меньше.
Спасибо, что подняли тему атмосферы. Окинул взглядом свой опыт, интересные наблюдения увидел.
Только у меня совсем противоположные вашим выводы получились. И тут пришло озарение: «адекватность» — это не синоним «лучшего». Деревянная ножка адекватна деревянному стулу, но неадекватна металлическому. И наоборот — металлическая ножка у деревянного стула выглядит неадекватно.
Получается, если человек внутренне нацелен на решение проблем и поиск решений, то для него адекватной атмосферой будет офис с постоянными факапами и покупкой печенек за свой счет. А если человек нацелен на последовательное развитие от основ к более глубокому, на длительные мыслительные процессы, планирование и анализ своего рабочего процесса, то тут адекватной атмосферой будет офис, в котором максимум пространства, печенек и свободного времени.
Если человек не хочет, чтобы его слова использовали против него — пусть их не произносит.
А уж если сказал — будь готов отвечать.
Боятся записи только лгуны и мошенники.
А если есть подозрения на подделку записи — вот тут и выручает запись Яровой или экспертиза.
Это фиаско
Есть красное русское слово для этого случая — «очковтирательство». Кажется, оно как нельзя лучше подходит для иллюстрации смысла планирования в сторипоинтах.
Отнюдь. «Мой» означает, что я использую эти критерии в работе. Вне зависимости мою или чужую работу планирую.
Критерии «известен-код, известно-что-делать, есть-все-требования» значительно точнее, чем «джун-мидл-сеньор» в вашем способе планирования. Вкупе с более точным инструментом измерения дают вообще фантастическую точность относительно спринтов через сторипоинты.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Вы говорите о создании продукта или о прикрытии зада перед начальством?
Мой спринт такой:
— если работал и помнишь код, где нужно поменять и знаешь как это поменять, то 0,5 часа
— если не работал с кодом, но понимаешь, что поменять нужно чуть — 1 час
— если понимаешь, что поменять чуть, но с кодом не работал, в архитектуру вникать нет смысла и нужно обсуждать с заказчиком нюансы — 2 часа
— создание новой фичи на знакомом коде без архитектурных изменений — 4 часа
— любые работы, вызывающие изменение бизнес-логики или архитектуры решения — 6 часов на старте, затем по итогам этих 6ти часов
— отсутствие точных требований к задаче — плюс 1 час к расчетному времени
— ввод в работу нового проекта (подготовка рабочего окружения, изучение архитектуры) — 3-4 часа в зависимости от стека
По этой сетке можно разложить любую задачу на подзадачи и вывести расчетное время готовности проекта.
Но это, конечно, если хватает знаний для декомпозиции. А если нет — берешь паузу и в свободное от работы время учишься там, где не хватает.
Продуктивный день разработчика 6 часов. За 20 лет работы не видел ни одного уникума, способного кодить 8 часов с перерывом на обед. Чай/кофе/перекуры легко съедают 2 часа рабочего времени. Да и санитарные нормы 45/15 в час не на пустом месте придуманы были.
Без морали.
Или вы подразумеваете конкретного работодателя?
Команда — не голосовая — это группа разнообразных объектов, способная решать какую-либо задачу или выполнять работу с измеряемым параметром эффективности.
Группа определяется путём обобществления, команда подбирается путём детализации. Т.е. в группе важно делать упор на то, что людей объединяет. В команде же важно, чем один человек отличается от другого и как это укладывается в общее дело.
Для группы замена одного члена другим не принципиальна — всё равно в группе у всех одинаковый признак группы и группа при этом не перестает быть группой. В команде же замена одного члена другим практически невозможна. Выбытие участника команды останавливает всю команду. Подбор замены не всегда возможен.
Если разложить на столе детали редуктора — это будет группа запчастей. Общий признак — они предназначены для редуктора. На столе могут лежать несколько разобранных редукторов и это всё будет одна группа запчастей редуктора.
Но если собрать часть запчастей в редуктор — это уже будет команда, применительно к технике — узел, агрегат — в котором каждый член выполняет свою индивидуальную функцию, а вместе они передают крутящий момент от источника к получателю.
1) В туалет ходят с туалетной бумагой, а в душ с полотенцем; и не наоборот. Агил используют в поддержке продукта, ватерфол в разработке.
2) Если для планирования нужна консультация кодера/разработчика, то лид/менеджер — никто. У каждого своя работа, писать код и строить планы — это разные вселенные. Менеджеру сдать проект нужно как можно быстрее, а разработчик хочет сделать как можно надежнее. Каким хреном они могут вообще сами договориться? Цели разные.
3) Команда — это не группа. В группе может быть сколько угодно каких угодно человек. Но в команде каждый человек берет на себя часть от 5ти ролей. И ранжировать людей джун-мидл-сеньор в команде невозможно, т.к. у всех разные роли и за счет этого команда действует как единый механизм.
А в целом всем нам знакомо, что происходит, когда молодого необразованного амбициозного человека назначают начальником над соплеменниками. Коллеги, не расслабляйтесь, изучите матчасть по скрамам, агилам, ватерфолам и командам. И посылайте недоменеджеров и недолидов сразу, как услышите их «фирменный» сленг («фасилитация», например).
Человеку свойственно за англицизмами и подменой понятий скрывать недостаток знаний и навыков.
На месте работодателя я бы попросил удалить эту статью, чтобы не позорить компанию.
Как это? Можете развить мысль?
ну, как бэ...
лет двадцать назад они отказались от части инвестиций в недвижимость, но общепит их бизнесом никогда и не был-то
Т.е. такого зверя, который одновременно открывает затвор и в тот же момент делает цифровой снимок для превью. Ну, чтобы моргунов можно было сразу переснять или получить представление об удачном кадре до того, как проявишь плёнку, в момент, когда еще можно что-то исправить.
Легко представить: звонок в дверь, на пороге почтальон такой «Вам пакет habr.com! Распишитесь»
То самое чувство, когда для существования Интернета сам Интернет и не нужен )
4. Уровень компьютерной грамотности большинства заказчиков ПО (руководителей или клиентов) ниже низкого. Из-за этого, их ТЗ выглядят как «нужно, чтобы программа делала это и то». Как именно, в каких случаях, как быстро — они не знают, список технических требований сформулировать не могут. По молодости такие проекты очень интересны — их делаешь по 2-3 раза, каждый раз уточняя и ликвидируя проблемы, возникающие при внедрении. Но к 35 годам после множества разработок уже на первых строках задачи клиента видишь, какие проблемы он огребёт в итоге. Разумеется, объясняешь, тогда либо проект сворачивают, либо тебя заворачивают. Проблема в том, что надоедает такая работа. Привлекает уже больше работать с профессионалами, которые знают, чего хотят и куда идут. А таких очень мало на пост-СССР территории.
По поводу фейка к пользователю претензий не будет.
В претензию станет «распространение недостоверной информации»
А по наказанию это столько же, как и создание фейковой новости
Другое дело, что заРКНить «распространителей контента» можно будет с легкой руки.
ну чо, подкопили на мечту ;)
Тут просто. Если DNS сервер будет работать по принципу HTTPS, то для получения надежного ответа, к нему нужно будет обращаться напрямую с использованием TLS. В этом случае ответ от сервера можно считать валидным, т.к. вероятность его подмены в пути очень мала.
Если TLSA записи передавать открытым текстом, то ничего не мешает на узле провайдера заменять данные своим сертификатом. Вкупе с возможностью организовать MiTM это вообще сводит к нулю идею HTTPS для сайтов.
Вопрос: Гугл пробивается вашими прокси? или как везде, через капчу?
Это тезисно. Если развернуть, объемный роман можно написать из этой темы.
Западные страны, пионеры автоматизации, на текущий момент решают проблему за счет восточных стран, вытягивая достойные кадры-самородки из РФ, Индии, Китая. Своих кадров у них нет и не может появиться, т.к. базы, на которой могут обучиться люди, у них практически нет — неавтоматизированных и недо-автоматизированных систем имеется в виду.
То, что случилось с бухгалтерами за последние 30 лет, ожидает и программистов через 5-10 лет. Пока зарплаты еще на уровне, но тренд на спад уже пошел, и реальной интересной работы становится всё меньше и меньше.
Только у меня совсем противоположные вашим выводы получились. И тут пришло озарение: «адекватность» — это не синоним «лучшего». Деревянная ножка адекватна деревянному стулу, но неадекватна металлическому. И наоборот — металлическая ножка у деревянного стула выглядит неадекватно.
Получается, если человек внутренне нацелен на решение проблем и поиск решений, то для него адекватной атмосферой будет офис с постоянными факапами и покупкой печенек за свой счет. А если человек нацелен на последовательное развитие от основ к более глубокому, на длительные мыслительные процессы, планирование и анализ своего рабочего процесса, то тут адекватной атмосферой будет офис, в котором максимум пространства, печенек и свободного времени.
Вроде как «кесарю-кесарево» получается.