:) Перфокарты были только для примера. Да и с ними не всё так просто. Ну, допустим, прочитали мы поток байтов с перфокарт. А дальше что? Там ведь когда-то раньше для этого наверняка какой-то софт был предназначен, со своей трудоёмкостью создания...
Ну а если что-то более технологичное себе представить? Ну, любой носитель для ленточного накопителя лет через 30… Устройств для чтения нет, элементная база для них — только в музеях, и спецификацию на формат данных тоже надо искать где-то, а потом ещё и реализовывать...
На мой взгляд вообще вряд ли стоит ставить задачу по выбору наилучшего носителя на длительный срок.
Перфоркарты вот наверно неплохо сохраняются, только вот что с ними делать сейчас, если вдруг надо будет сегодня прочитать какой-нибудь архив на перфокартах? :) А случаи такие бывают, как рассказывают…
Я бы подходил к задаче архивирования на длительный срок в первую очередь как к периодическому процессу, который включал бы в себя регулярный анализ сохранности данных, повторный выбор технологии хранения и перезаписывание всей информации.
Ну и все остальные соображения про избыточность, независимое хранение различных экземпляров и т.п. тоже, конечно, играют...
Ну вот как я понимаю, именно это и требуется: не грузить и не подключать никаких механизмов от третьих сторон, которые могут выставлять свои куки, пока посетитель не даст на то своего явного согласия...
И я по правде тоже не понял, для какой из декларированных задач куков не хватило…
Если исходить из тезиса, что главное зло — в логинах с паролями — ну, тогда просто аутентифицировать / идентифицировать посетителя теми средствами, которые нравятся.
Ну а чем куки плохи для сохранения информации о сеансе — непонятно...
Как мне видится, технические вещи типа CORS — сами по себе, и заголовки какие нужны, чтобы браузер согласился со всей конструкцией работать, такие и нужны.
А юридические вопросы — сами по себе. Как на той же самой странице чуть ниже пишут, всё что надо — это:
показать сообщение про куки;
обеспечить отсутствие third-party куков, пока не будет получено согласие посетителя;
разумно после этого создать куки на весь портал, чтобы не переспрашивать одно и то же на разных поддоменах.
Про куки всё так. Не со всеми куками борьба идёт, а только с third-party…
А в отношении технически необходимых first-party куков есть понимание, что отменить их нельзя, и даже согласие пользователя на их использование не требуется: wikis.ec.europa.eu/display/WEBGUIDE/04.+Cookies
Ну, я наверно слово не самое удачное выбрал :) Наверно лучше не о командах говорить, а о группах… или о сегментах… А то, что трудоёмкость надо оценивать с учётом специализации участников — вроде нет наверно возражений ни у кого…
Есть для автора рецепт, как можно почувствовать себя «настоящим», не меняя радикально профиля работы и основных навыков.
Если сейчас местом работы является какой-нибудь франчайзи или другой подобный центр разработки решений на основе 1С, то просто сменить его на любую фирму, в которой 1С используется, и где используемое решение — достаточно кастомное, чтобы использование своего программиста было оправданным. Ну и характер бизнеса фирмы должен при этом нравиться. В терминологии автора — должен быть «настоящим».
Ну а дальше всё должно сложиться само. Пользователи и менеджмент нагенерят задач, все задачи (после фильтрации) будут реально полезны, и поток морального удовлетворения на каждый день гарантирован :)
Рассказ прикольный, только имхо он в первую очередь про то, как можно испортить полезную вещь, забывши про RTFM… :)
Почему «Agile мотивирует нас принимать… легковесные решения»? Быстрые — да. А легковесные-то почему? Кто запрещает ещё и думать при этом? :) Если нужное решение не нашлось — ну перенесли задачу на следующий спринт, а на текущем выделили время на её дополнительную проработку в виде отдельной подзадачи…
Про краткосрочность проектов тоже не очевидно. Знаю проекты по рефакторингу крупных систем, которые месяцами, если не годами, живут по аджайлу, и вроде нормально живут: заказчики довольны, фичи новые внедряются…
Аджайл — это просто принцип, и отключение головы в нём не предусмотрено :) Если нужен на проекте архитектор — значит нужно, чтобы команда была им укомплектована. Если разработчиков много — значит нужны лиды в необходимом количестве и время у них на то, чтобы менторить и ревьюить всё, что надо. И надо, чтобы каждый понимал, за что отвечает лично он, и за что — его смежник. И чтобы матрица эта была без пустот… И всё норм будет… :)
«А я потерял веру в эффективность внедрения систем управления задачами, равно как и в эффективность менеджмента. Нет смысла тратить время на эффективность исполнения, автоматизируя контроль задач. Потому что столкнетесь с реальным кризисом управления – окажется, что никто не знает, что надо делать.» — Ну а почему так уж сразу? :)
Просто действительно проблемы эти надо решать в комплексе — и ИТ-шные, и управленческие. И хорошо бы, чтобы участники все играли в одну игру, а не каждый в свою…
Ну а для того надо не забывать ставить себе внятные цели, а потом регулярно проверять их достижение и анализировать результаты. И анализировать, что происходит и почему. И новые скорректированные планы строить с учётом новой ситуации и накопленного опыта.
Ну и конечно вряд ли что-нибудь путное получится, если относиться к персоналу исключительно как к ресурсу и выстраивать взаимодействие с людьми как к с квадратиками из схемы… Люди всё равно богаче квадратиков по своим проявлениям :) Лучше привлекать их на свою сторону, а вот как — тут уже думать надо, причём на регулярной основе :)
А инструмент для автоматизации по большому счёту не виноват, и программист не виноват… Просто забыли про анализ достижений и их причин… Или не сложилось что-то с этим…
Да и вообще все велосипеды изобретены уже :) Вот в стандарте ISO 9001 рассмотрено всё. Хоть он и называется про менеджмент качества, но на самом деле там всё про менеджмент процессов и про достижение целей. Ну, не лёгкое чтение он, может быть, для свежего глаза, но наверняка популярных изложений много найдётся, если поискать…
:) Перфокарты были только для примера. Да и с ними не всё так просто. Ну, допустим, прочитали мы поток байтов с перфокарт. А дальше что? Там ведь когда-то раньше для этого наверняка какой-то софт был предназначен, со своей трудоёмкостью создания...
Ну а если что-то более технологичное себе представить? Ну, любой носитель для ленточного накопителя лет через 30… Устройств для чтения нет, элементная база для них — только в музеях, и спецификацию на формат данных тоже надо искать где-то, а потом ещё и реализовывать...
На мой взгляд вообще вряд ли стоит ставить задачу по выбору наилучшего носителя на длительный срок.
Перфоркарты вот наверно неплохо сохраняются, только вот что с ними делать сейчас, если вдруг надо будет сегодня прочитать какой-нибудь архив на перфокартах? :) А случаи такие бывают, как рассказывают…
Я бы подходил к задаче архивирования на длительный срок в первую очередь как к периодическому процессу, который включал бы в себя регулярный анализ сохранности данных, повторный выбор технологии хранения и перезаписывание всей информации.
Ну и все остальные соображения про избыточность, независимое хранение различных экземпляров и т.п. тоже, конечно, играют...
Ну вот как я понимаю, именно это и требуется: не грузить и не подключать никаких механизмов от третьих сторон, которые могут выставлять свои куки, пока посетитель не даст на то своего явного согласия...
И я по правде тоже не понял, для какой из декларированных задач куков не хватило…
Если исходить из тезиса, что главное зло — в логинах с паролями — ну, тогда просто аутентифицировать / идентифицировать посетителя теми средствами, которые нравятся.
Ну а чем куки плохи для сохранения информации о сеансе — непонятно...
Как мне видится, технические вещи типа CORS — сами по себе, и заголовки какие нужны, чтобы браузер согласился со всей конструкцией работать, такие и нужны.
А юридические вопросы — сами по себе. Как на той же самой странице чуть ниже пишут, всё что надо — это:
А в отношении технически необходимых first-party куков есть понимание, что отменить их нельзя, и даже согласие пользователя на их использование не требуется:
wikis.ec.europa.eu/display/WEBGUIDE/04.+Cookies
Если сейчас местом работы является какой-нибудь франчайзи или другой подобный центр разработки решений на основе 1С, то просто сменить его на любую фирму, в которой 1С используется, и где используемое решение — достаточно кастомное, чтобы использование своего программиста было оправданным. Ну и характер бизнеса фирмы должен при этом нравиться. В терминологии автора — должен быть «настоящим».
Ну а дальше всё должно сложиться само. Пользователи и менеджмент нагенерят задач, все задачи (после фильтрации) будут реально полезны, и поток морального удовлетворения на каждый день гарантирован :)
Почему «Agile мотивирует нас принимать… легковесные решения»? Быстрые — да. А легковесные-то почему? Кто запрещает ещё и думать при этом? :) Если нужное решение не нашлось — ну перенесли задачу на следующий спринт, а на текущем выделили время на её дополнительную проработку в виде отдельной подзадачи…
Про краткосрочность проектов тоже не очевидно. Знаю проекты по рефакторингу крупных систем, которые месяцами, если не годами, живут по аджайлу, и вроде нормально живут: заказчики довольны, фичи новые внедряются…
Аджайл — это просто принцип, и отключение головы в нём не предусмотрено :) Если нужен на проекте архитектор — значит нужно, чтобы команда была им укомплектована. Если разработчиков много — значит нужны лиды в необходимом количестве и время у них на то, чтобы менторить и ревьюить всё, что надо. И надо, чтобы каждый понимал, за что отвечает лично он, и за что — его смежник. И чтобы матрица эта была без пустот… И всё норм будет… :)
Просто действительно проблемы эти надо решать в комплексе — и ИТ-шные, и управленческие. И хорошо бы, чтобы участники все играли в одну игру, а не каждый в свою…
Ну а для того надо не забывать ставить себе внятные цели, а потом регулярно проверять их достижение и анализировать результаты. И анализировать, что происходит и почему. И новые скорректированные планы строить с учётом новой ситуации и накопленного опыта.
Ну и конечно вряд ли что-нибудь путное получится, если относиться к персоналу исключительно как к ресурсу и выстраивать взаимодействие с людьми как к с квадратиками из схемы… Люди всё равно богаче квадратиков по своим проявлениям :) Лучше привлекать их на свою сторону, а вот как — тут уже думать надо, причём на регулярной основе :)
А инструмент для автоматизации по большому счёту не виноват, и программист не виноват… Просто забыли про анализ достижений и их причин… Или не сложилось что-то с этим…
Да и вообще все велосипеды изобретены уже :) Вот в стандарте ISO 9001 рассмотрено всё. Хоть он и называется про менеджмент качества, но на самом деле там всё про менеджмент процессов и про достижение целей. Ну, не лёгкое чтение он, может быть, для свежего глаза, но наверняка популярных изложений много найдётся, если поискать…