Такое поведение не только не очевидно, но и становится опасным тем, кто регулярно чистит историю переписок, и ощущая свою безопасность, может предоставить злоумышленнику доступ к аккаунту.
Возникает вопрос, зачем так делать? Это очень порочная практика. Плюс, люди пользуются системой, о реальной работе которой они ничего не знают, но почему-то считают, что она будет вести себя именно так, как они ожидают.
Спасибо за подборку, она действительно интересная, увидел тут много знакомых сервисов.
К сожалению, это поставило многих авторов в затруднительное положение. Авторы часто оказываются в удручающем положении, когда они в значительной степени полагаются на платформы в качестве источника дохода, но почти не имеют контроля над тем, как эти платформы работают. В любой момент платформа может лишить их потока доходов или поставить под сомнение всю их бизнес-модель.
Сидеть на бонусных выплатах от платформы в качестве важного источника средств - это не бизнес-модель, это своеобразная форма цифрового попрошайничества. Почти все платформы говорят авторам практически напрямую "вы здесь никто" в договорах, но люди перестают делать вид, что не замечают этого, когда им закрывают доступ к деньгам или к платформе в целом.
Ключевое отличие предпринимателя от наемного работника в том, что первый может ставить и достигать не просто цели, а те цели, которые принесут ему доход. Условный разработчик абсолютно легко может поставить себе цель автоматизировать какой-то процесс, что сэкономит 50 тысяч рублей, в то время как на автоматизацию потрачено 500 тысяч. Предприниматель редко может себе такое позволить.
Тут вопрос более интересный: если это инициатива HR, то почему условный начальник/начальник начальника/начальник начальника начальника/… не скажет, что у них есть утверждённые регламенты, где этого бреда нет, их сотрудники не будут заполнять анкету, а будут премироваться по стандартному регламенту? И если HR хотят что-то такое проводить, то пусть согласуют с бизнесом трату стольки-то часов разработчиков, которые стоят столько денег. Или же есть нюанс, и почему-то руководство ИТ и бизнеса заинтересовано в оценках?
Проблема почти всех таких статей в том, что они описывают очень абстрактные команды без анализа требований к сотрудникам и их результатам.
Где-то можно нанять примерно любого разработчика, и процесс разработки будет идти. Многие, даже очень большие проекты, в реальности очень просты. И там не нужны ни новые технологии (хотя разраб будет с большим удовольствием рассказывать про новейшие находки), ни правильное применение лучших практик (хотя эти же люди будут выступать на конференциях и рассказывать про нюансы проектирования). А где-то не подойдёт прикольный и дружелюбный чувак, там нужен человек, который реально понимает, как и что работает, и что он делает.
Я встречал одну из самых приятных и комфортных команд, где люди реально рассказывали о нюансах технологий, они умело рассуждали почти обо всем в ИТ, но этим не пользовались, и не умели пользоваться. И они годами делали систему, которую потом переписывали полгода, с истериками, конфликтами и взаимными обвинениями, так как она не подходила под формализованные требования заказчика по безопасности и стабильности.
Сама статья бессмысленна и непрлфессиональна, учитывая регулярные проблемы с безналичными платежами, думаю, что сотрудники банка читают и испытывают стыд. Но с одним не согласен абсолютно:
Японские деньги на этом фоне выглядят просто невзрачно.
Японские деньги выглядят очень круто и достойно. Их приятно держать в руках, они не выглядят как попытка нарисовать рекламный баннер на купюре.
Невыплата зарплаты, которая была обещана (а подписываются под 40 часов в неделю + сверхурочные обычно через явное письменное подтверждение от руководства, приказы на работы и подобное), - это весьма серьёзное обвинение. Если это так, то будет круто, если профсоюз поможет сформулировать заявление в суд. Работник должен получать те деньги, которые были ему обещаны.
Если же это история про «Мы обещали сделать за две недели, а оказалось, что делаем это два месяца, менеджмент плохой, на нас давит», то тут ситуация обратная. И вопросы большие к работникам.
Беда в том, что косяки со сроками и качеством проектов зачастую влияют на бизнес в меньшей степени, чем на коллег. Условно, разработчики тормозят, растёт нагрузка на тестировщиков, у девопсов постоянно падают системы, поддержка разбирает сложные обращения. В идеальном мире задача профсоюза - не только борьба за «Больше зарплаты, лучше условия», но и контроль внутренних конфликтов и нарушений, так как они доставляют часто гораздо больше проблем.
Меня и мою команду лично не принуждали к подработкам, всё-таки дело добровольное. Но если твоя команда соглашается с такими спринтами, то на тебя могут надавить
Я правильно понимаю, что если люди взяли на себя ответственность и подписались под какими-то обязательствами, то от них начинают требовать их исполнения? Шок…
В этом и идея, что пользователям разумнее просить зафиксировать условия в устраивающем всех состоянии, условно «Мы платим Х, вы храните данные Y лет», а не пытаться что-то вытребовать, хотя все обязательства уже записаны и подписаны при регистрации.
Имхо, в такой ситуации «протестующим» разумнее предложить какой-то выгодный вариант. Например, бесплатные аккаунты живут 2 года с момента последней активности, заплатил 100 долларов - аккаунт живет ещё 5 лет. Проблема хранения старых данных - сложная задача, подходить к ней с точки зрения «Нельзя удалять, это моя история, храните годами, да, я пользуюсь бесплатно» очень странно
Мне очень интересен формат этой рубрики: вы будете собирать все отзывы, проверять их подлинность и публиковать их все? Или это будет выборочная публикация самых интересных отзывов, которая часто сводится к выбору наиболее драматичных, ярких и необычных? По моему опыту, в ИТ есть достаточно много конфликтных людей, которые очень хотят насолить бывшим коллегам после увольнения. И я бы не хотел превращения Хабра в такую площадку, даже если часть таких историй будет правдива.
Тут я согласен, что часто попытка использовать правильный и оптимальный подход может помешать увидеть простое неочевидное решение. Но, что занятно, часто для того, чтобы понять, что простое решение реально можно использовать, требуется большая квалификация, чем для того, чтобы просто использовать типовой подход.
Имхо, есть две крупных группы тех, кто не любит алгоритмы: те, кто понимает, как устроены алгоритмы, но не знает/забыл/не изучал детали, и те, кто не понимает, и поэтому не знает.
К людям из первой группы особых вопросов нет: если надо, они прочитают описание, поймут принцип работы и напишут сами достаточно хорошо. Например, человек решил не тратить время на то, что ему не интересно, его право.
А вот вторая группа вызывает очень много вопросов: почему человек не может понять принцип работы не очень сложных алгоритмов? С чем это связано? А какие ещё вещи из ИТ он не может понять? Недавно столкнулся с великолепной ситуацией: группа разработчиков не могла понять примерно два дня, что именно делает их код (который они частично написали сами, частично скопировали из разных источников). Верхнеуровнево все понятно, а вот что именно происходит в коде люди не могли понять. И их руководитель краснел от стыда и говорил, что ребята реально не понимают, что делает их код, хотя они же его и собрали.
Это могло бы произойти вообще по любой другой причине, начиная с того, что в Яндексе что-то там сломалось, заканчивая тем, что Яндекс вдруг объявил что теперь все колонки будут официально прослушивать все разговоры всех людей, и всю инфу докладывать в полицию.
Между «Могло произойти» и «Произошло» очень большая разница. Смысл многих действий не в том, чтобы убрать риски (часто это невозможно), а их минимизировать.
Запускать новые в любом случае нужно. Даже при неудаче нельзя пойти в уголочек, посыпать голову пеплом и перестать выпускать колонки.
Все ещё спорно, нужно ли их запускать сразу после достаточно серьезного репутационного инцидента?
Я не говорю, что колонки надо сворачивать, что направление умерло. Я говорю, что меня крайне смущает и удивляет, что сначала наносится серьезный репутационный ущерб (опыт многих компаний и здравый смысл показывают, что включение рекламы раздражает пользователей, особенно, если они платили за какую-то подписку), а потом запускаются продажи колонок. При включении рекламы сотрудники не могли не знать, что будут продажи новых колонок, но рекламу запустили, огребли волну негатива. Зачем и почему? Не знаю, но адекватного объяснения у меня нет.
У меня есть стойкое ощущение, что с колонками происходит какая-то внутренняя диверсия в Яндексе:
Сначала резко включить рекламу на колонках без возможности отключения
Потом придумать издевательские ответы про то, что это сделано для того, чтобы больше людей узнало об услугах партнёров
И после того, как у кучи людей пропадает желание покупать колонки, запустить продажи новых
Лично для меня это выглядит либо как крайне странное решение на грани с некомпетентностью, либо как сознательная попытка снизить продажи. Я бы на месте сотрудников начинал бы очень серьёзные проверки происходящего
Возможно, что множество статей и курсов «Как хакнуть собеседование и устроиться в компанию мечты» и «Я не успеваю в рабочее время справиться с рабочими задачами» как-то связано друг с другом…
А так - статье не хватает конкретики: разработчики перерабатывают из-за того, что не успевают? Или работают за сверхурочные, так как бизнес готов за это платить?
Имхо, один из самых важных моментов - не надо легализовывать бардак. Одна из задач QA - обеспечение качества процессов, сопровождающих разработку. Ошибки и недоработки других команд - это не нормальные условия, к которым надо привыкать тестировщику, а проблемы, с которыми надо бороться.
Если условные аналитики плохо описывают функционал, то стоит искать способы давления на них: через тех, кто от этого страдает, через безопасников (если они есть). Люди должны работать нормально, а не сваливать исправление своих косяков на коллег. Не «Горят сроки, надо сегодня выпустить релиз», а «Я решил выслужиться перед заказчиком, понимаю риски недостаточного тестирования и невозможности его проведения в такой срок, ответственность несу единолично сам».
Часто проблемы возникают в том числе из-за того, что многие люди достаточно умные и хитрые не только для того, чтобы работать хорошо, и придумывать решения для сложных задач, но и для того, чтобы умело скидывать ответственность, получая ништяки. Условный начальник взял ещё один проект на отдел, получил +20% денег, качество упало, а в этом уже виноваты тестировщики.
Поэтому важно напоминать начинающим специалистам, что не надо брать на себя ответственность за ошибки других. Это не значит, что не надо помогать коллегам, наоборот. Но только с явным пониманием у всех участников процесса, кто виноват в проблеме, и что сотрудник вытаскивает проект из болота, а не сидит по 10 часов в день и все равно не делает все из-за того, что он тупой.
Доверив свои портфели сертифицированному профессионалу по управлению портфелями Portfolio Management Professional® (PfMP®), компании могут быть уверены, что их ресурсы и средства расходуются эффективно и на нужные инициативы.
Звучит красиво. Тут главный вопрос - PMI как-то это гарантирует, несёт финансовую ответственность или страхует компании от нарушения со стороны сертифитированного сотрудника? Или это больше, к сожалению, сертификат о получении сертификата?
Думаю, что ключевое слово тут - «тогда». Наверное, на каком-то этапе сумасшедшие или укурки могут быть полезны. Главный вопрос - это последствия. Одно дело - потерять условные 100 тысяч, если странный человек что-то сделает, а другое - потерять 100 миллионов и получить гору исков.
Но сейчас есть другая интересная ситуация, один из довольно известных HR говорил примерно следующее: «Сейчас есть куча кандидатов, которые настолько психически не здоровы, что они вообще не годны в армию, не могут получить водительские права, но при этом их без вопросов нанимают, чтобы они разрабатывали что-то важное или управляли критичными системами»
Возникает вопрос, зачем так делать? Это очень порочная практика. Плюс, люди пользуются системой, о реальной работе которой они ничего не знают, но почему-то считают, что она будет вести себя именно так, как они ожидают.
Спасибо за подборку, она действительно интересная, увидел тут много знакомых сервисов.
Сидеть на бонусных выплатах от платформы в качестве важного источника средств - это не бизнес-модель, это своеобразная форма цифрового попрошайничества. Почти все платформы говорят авторам практически напрямую "вы здесь никто" в договорах, но люди перестают делать вид, что не замечают этого, когда им закрывают доступ к деньгам или к платформе в целом.
Ключевое отличие предпринимателя от наемного работника в том, что первый может ставить и достигать не просто цели, а те цели, которые принесут ему доход. Условный разработчик абсолютно легко может поставить себе цель автоматизировать какой-то процесс, что сэкономит 50 тысяч рублей, в то время как на автоматизацию потрачено 500 тысяч. Предприниматель редко может себе такое позволить.
Тут вопрос более интересный: если это инициатива HR, то почему условный начальник/начальник начальника/начальник начальника начальника/… не скажет, что у них есть утверждённые регламенты, где этого бреда нет, их сотрудники не будут заполнять анкету, а будут премироваться по стандартному регламенту? И если HR хотят что-то такое проводить, то пусть согласуют с бизнесом трату стольки-то часов разработчиков, которые стоят столько денег. Или же есть нюанс, и почему-то руководство ИТ и бизнеса заинтересовано в оценках?
Проблема почти всех таких статей в том, что они описывают очень абстрактные команды без анализа требований к сотрудникам и их результатам.
Где-то можно нанять примерно любого разработчика, и процесс разработки будет идти. Многие, даже очень большие проекты, в реальности очень просты. И там не нужны ни новые технологии (хотя разраб будет с большим удовольствием рассказывать про новейшие находки), ни правильное применение лучших практик (хотя эти же люди будут выступать на конференциях и рассказывать про нюансы проектирования). А где-то не подойдёт прикольный и дружелюбный чувак, там нужен человек, который реально понимает, как и что работает, и что он делает.
Я встречал одну из самых приятных и комфортных команд, где люди реально рассказывали о нюансах технологий, они умело рассуждали почти обо всем в ИТ, но этим не пользовались, и не умели пользоваться. И они годами делали систему, которую потом переписывали полгода, с истериками, конфликтами и взаимными обвинениями, так как она не подходила под формализованные требования заказчика по безопасности и стабильности.
Не смотря на то, что я очень плохо отношусь к различным «ревью», именно эта ситуация выглядит комично и справедливо:
Людям говорят определить цели и планы, они считают это необязательным, игнорируют. Выполнять тоже не спешат:
«Желания выполнять цели, которые практически были высосаны тобой из пальца, дабы соответствовать количеству в n* штук - особо не было.»
Руководство решает не выплачивать необязательную премию тем, кто решил не выполнять поставленные задачи:
Мы демотивированы, это нечестно
Сама статья бессмысленна и непрлфессиональна, учитывая регулярные проблемы с безналичными платежами, думаю, что сотрудники банка читают и испытывают стыд. Но с одним не согласен абсолютно:
Японские деньги выглядят очень круто и достойно. Их приятно держать в руках, они не выглядят как попытка нарисовать рекламный баннер на купюре.
Невыплата зарплаты, которая была обещана (а подписываются под 40 часов в неделю + сверхурочные обычно через явное письменное подтверждение от руководства, приказы на работы и подобное), - это весьма серьёзное обвинение. Если это так, то будет круто, если профсоюз поможет сформулировать заявление в суд. Работник должен получать те деньги, которые были ему обещаны.
Если же это история про «Мы обещали сделать за две недели, а оказалось, что делаем это два месяца, менеджмент плохой, на нас давит», то тут ситуация обратная. И вопросы большие к работникам.
Беда в том, что косяки со сроками и качеством проектов зачастую влияют на бизнес в меньшей степени, чем на коллег. Условно, разработчики тормозят, растёт нагрузка на тестировщиков, у девопсов постоянно падают системы, поддержка разбирает сложные обращения. В идеальном мире задача профсоюза - не только борьба за «Больше зарплаты, лучше условия», но и контроль внутренних конфликтов и нарушений, так как они доставляют часто гораздо больше проблем.
Я правильно понимаю, что если люди взяли на себя ответственность и подписались под какими-то обязательствами, то от них начинают требовать их исполнения? Шок…
В этом и идея, что пользователям разумнее просить зафиксировать условия в устраивающем всех состоянии, условно «Мы платим Х, вы храните данные Y лет», а не пытаться что-то вытребовать, хотя все обязательства уже записаны и подписаны при регистрации.
Имхо, в такой ситуации «протестующим» разумнее предложить какой-то выгодный вариант. Например, бесплатные аккаунты живут 2 года с момента последней активности, заплатил 100 долларов - аккаунт живет ещё 5 лет. Проблема хранения старых данных - сложная задача, подходить к ней с точки зрения «Нельзя удалять, это моя история, храните годами, да, я пользуюсь бесплатно» очень странно
Мне очень интересен формат этой рубрики: вы будете собирать все отзывы, проверять их подлинность и публиковать их все? Или это будет выборочная публикация самых интересных отзывов, которая часто сводится к выбору наиболее драматичных, ярких и необычных? По моему опыту, в ИТ есть достаточно много конфликтных людей, которые очень хотят насолить бывшим коллегам после увольнения. И я бы не хотел превращения Хабра в такую площадку, даже если часть таких историй будет правдива.
Тут я согласен, что часто попытка использовать правильный и оптимальный подход может помешать увидеть простое неочевидное решение. Но, что занятно, часто для того, чтобы понять, что простое решение реально можно использовать, требуется большая квалификация, чем для того, чтобы просто использовать типовой подход.
Имхо, есть две крупных группы тех, кто не любит алгоритмы: те, кто понимает, как устроены алгоритмы, но не знает/забыл/не изучал детали, и те, кто не понимает, и поэтому не знает.
К людям из первой группы особых вопросов нет: если надо, они прочитают описание, поймут принцип работы и напишут сами достаточно хорошо. Например, человек решил не тратить время на то, что ему не интересно, его право.
А вот вторая группа вызывает очень много вопросов: почему человек не может понять принцип работы не очень сложных алгоритмов? С чем это связано? А какие ещё вещи из ИТ он не может понять? Недавно столкнулся с великолепной ситуацией: группа разработчиков не могла понять примерно два дня, что именно делает их код (который они частично написали сами, частично скопировали из разных источников). Верхнеуровнево все понятно, а вот что именно происходит в коде люди не могли понять. И их руководитель краснел от стыда и говорил, что ребята реально не понимают, что делает их код, хотя они же его и собрали.
Между «Могло произойти» и «Произошло» очень большая разница. Смысл многих действий не в том, чтобы убрать риски (часто это невозможно), а их минимизировать.
Все ещё спорно, нужно ли их запускать сразу после достаточно серьезного репутационного инцидента?
Я не говорю, что колонки надо сворачивать, что направление умерло. Я говорю, что меня крайне смущает и удивляет, что сначала наносится серьезный репутационный ущерб (опыт многих компаний и здравый смысл показывают, что включение рекламы раздражает пользователей, особенно, если они платили за какую-то подписку), а потом запускаются продажи колонок. При включении рекламы сотрудники не могли не знать, что будут продажи новых колонок, но рекламу запустили, огребли волну негатива. Зачем и почему? Не знаю, но адекватного объяснения у меня нет.
У меня есть стойкое ощущение, что с колонками происходит какая-то внутренняя диверсия в Яндексе:
Сначала резко включить рекламу на колонках без возможности отключения
Потом придумать издевательские ответы про то, что это сделано для того, чтобы больше людей узнало об услугах партнёров
И после того, как у кучи людей пропадает желание покупать колонки, запустить продажи новых
Лично для меня это выглядит либо как крайне странное решение на грани с некомпетентностью, либо как сознательная попытка снизить продажи. Я бы на месте сотрудников начинал бы очень серьёзные проверки происходящего
Возможно, что множество статей и курсов «Как хакнуть собеседование и устроиться в компанию мечты» и «Я не успеваю в рабочее время справиться с рабочими задачами» как-то связано друг с другом…
А так - статье не хватает конкретики: разработчики перерабатывают из-за того, что не успевают? Или работают за сверхурочные, так как бизнес готов за это платить?
Имхо, один из самых важных моментов - не надо легализовывать бардак. Одна из задач QA - обеспечение качества процессов, сопровождающих разработку. Ошибки и недоработки других команд - это не нормальные условия, к которым надо привыкать тестировщику, а проблемы, с которыми надо бороться.
Если условные аналитики плохо описывают функционал, то стоит искать способы давления на них: через тех, кто от этого страдает, через безопасников (если они есть). Люди должны работать нормально, а не сваливать исправление своих косяков на коллег. Не «Горят сроки, надо сегодня выпустить релиз», а «Я решил выслужиться перед заказчиком, понимаю риски недостаточного тестирования и невозможности его проведения в такой срок, ответственность несу единолично сам».
Часто проблемы возникают в том числе из-за того, что многие люди достаточно умные и хитрые не только для того, чтобы работать хорошо, и придумывать решения для сложных задач, но и для того, чтобы умело скидывать ответственность, получая ништяки. Условный начальник взял ещё один проект на отдел, получил +20% денег, качество упало, а в этом уже виноваты тестировщики.
Поэтому важно напоминать начинающим специалистам, что не надо брать на себя ответственность за ошибки других. Это не значит, что не надо помогать коллегам, наоборот. Но только с явным пониманием у всех участников процесса, кто виноват в проблеме, и что сотрудник вытаскивает проект из болота, а не сидит по 10 часов в день и все равно не делает все из-за того, что он тупой.
Звучит красиво. Тут главный вопрос - PMI как-то это гарантирует, несёт финансовую ответственность или страхует компании от нарушения со стороны сертифитированного сотрудника? Или это больше, к сожалению, сертификат о получении сертификата?
Думаю, что ключевое слово тут - «тогда». Наверное, на каком-то этапе сумасшедшие или укурки могут быть полезны. Главный вопрос - это последствия. Одно дело - потерять условные 100 тысяч, если странный человек что-то сделает, а другое - потерять 100 миллионов и получить гору исков.
Но сейчас есть другая интересная ситуация, один из довольно известных HR говорил примерно следующее: «Сейчас есть куча кандидатов, которые настолько психически не здоровы, что они вообще не годны в армию, не могут получить водительские права, но при этом их без вопросов нанимают, чтобы они разрабатывали что-то важное или управляли критичными системами»