До определенного возраста дети учатся поведению у окружающего.
Не «учатся взаимодействовать», а именно учатся поведению — примеряют на себя ролевые модели с окружающего. Поэтому социализация в том смысле, который в это слово вкладываете вы, лет до 10-12 лучше происходит со взрослыми.
Это естественно не значит, что нужно ограждать от детей — напротив, общение со сверстниками тоже очень важно и нужно — ролевые модели, полученные от взрослых тоже где-то нужно проверять. Я хочу сказать, что это общение переоценено. Несколько друзей, дети родственников или дети друзей семьи, детский коллектив на кружках — этого вполне достаточно. Годам к 10-12 дети уже начинают активно интересоваться и незнакомым окружением — тогда уже нужно давать возможность им этот интерес реализовать (и это тоже не значит «бросить в толпу, а дальше пусть попытается выплыть сам»).
В защиту «школьной социализации» возможно скажу лишь, что это пожалуй единственное место кроме семьи, в котором у детей есть возможность как-то строить отношения со сверстниками на всю жизнь (несколько лет для них это воспринимается как вся жизнь).
Я здесь не знаю насколько это важно, и у всех ли это получается, я здесь указываю на момент, который я упускаю, но который может оказаться важен (а может и не оказаться).
Если перевести на язык программистов, к примеру: у тебя в форме входа нет валидации на поле е-мейл, нет защиты от SQL-инъекций, пароли хранятся в базе в открытом тексте, при проверке логина вычитывается из базы запись о пользователе целиком несмотря на то, что нам нужен только логин, плюс наверняка есть еще несколько багов про которые мы не знаем.
У тебя угнали пароли пользователей через форму входа, в чем корневая и единственная причина этого инцидента?
Чаще всего у инцидента не одна «корневая» причина, а целая серия обстоятельств, которые произошли одновременно.
Если бы какой-то части обстоятельств не было (даже одного) — инцидента могло бы вообще не быть.
Похожая тема — в разборах причин автокатастроф, см википедию, там тоже так же, например: не сделали что-то здесь во время обслуживания, сломалось что-то там, совпали погодные условия, ошибка в документации на самолет (и как следствие конкретная ошибка пилота) — в результате авария. Не было бы хотя бы чего-то одного из этого — самолет нормально долетел бы резервных мощностях.
PureData это не модульный синт, а скорее язык программирования.
Суть похожа, конечно, но сравнивать модуляры и пюредату это как сравнивать scratch и python.
Почему это может быть полезно? Потому что, наблюдая за пассажирами, можно придумать киллер-фичу. Ну или просто понять, как сделать людям удобнее, и сказать продуктологу. А дальше поменять мир. Немного. И не сразу
Рассказ очень интересный, но конкретно здесь — почему бы сразу продуктолога не отправить на электричках? :-)
Цена лопаты продаваемой в центре Москвы и в райцентре одинаковая будет или нет? А в другом райцентре? А на селе? А в соседнем селе? А насколько будет отличаться? А если продает твой друг Сёма? А если он с похмелья и срочно нужны деньги?
Приблизительно то сказать наверное можно, а вот точно — очень вряд ли. Поэтому я и говорю что объективно определить цену нельзя. Хотя конечно это будет сильно зависеть от желаемой точности.
А, прошу прощения, забираю слова назад, я прочитал это как «себестоимость производства».
Я бы поспорил про возможность объективного определения цены для «физического устройства и потребностей клиентов», но для этого нужен контекст, а я его уже утратил.
Я большую часть того что здесь написано не понял :-)
В глаза бросились несколько моментов:
* Затоваривание нехарактерно для монополии в сфере услуг. Цена на услугу у монополиста не будет падать так же как в случае с товарами. Скорее всего, это же можно сказать для товаров с ограниченным сроком хранения (например, продуктами)
* Говоря о тэта нужно говорить и о механизмах обратной связи в которых она фигурирует. Условному сборщику налогов без разницы знают его имя или нет. Ему все равно, что о нем подумают те, с кого он собирает налоги. Пока нет обратной связи — например, через закон, начальство или соседей.
Цена не связана с физическим устройством товара вообще никак. Чаще всего (и то не всегда) единственная связь — она не может быть ниже затрат понесенных на производство.
dph
Как лучше масштабировать ваш подход?
Предположим, запускается новый проект, но сразу ясно, что он будет сильно расти.
Сейчас команда маленькая, скажем 3 человека, но мы понимаем, что через год уже будет 10 человек (и это уже практически 2 команды, не одна).
А через два года 20 человек, и это уже наверняка 3-4 команды.
Проводить «смену методологии» при каждой фазе росте? Отдавать выбор методологии на откуп тимлидам? Подобрать методологию так, что можно будет ее продолжать использовать и при росте? Какой-то другой вариант?
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
Пара комментариев:
модели в формате
*.archimateкажется сейчас не поддерживаются — можно для себя чуть переписатьentrypoint.shи тогда все заработаетимена файлов на русском не поддерживаются
В остальном все супер, спасибо!
Небольшая поправка: "Snapshot" — это не скриншоты, это HTML со всеми включенными в него картинками, этакий "снимок" страницы.
Спасибо за статью, очень полезно!
Польза от участия в конфликтах есть только если ты научился выходить из них без проигрыша, разве нет?
Не «учатся взаимодействовать», а именно учатся поведению — примеряют на себя ролевые модели с окружающего. Поэтому социализация в том смысле, который в это слово вкладываете вы, лет до 10-12 лучше происходит со взрослыми.
Это естественно не значит, что нужно ограждать от детей — напротив, общение со сверстниками тоже очень важно и нужно — ролевые модели, полученные от взрослых тоже где-то нужно проверять. Я хочу сказать, что это общение переоценено. Несколько друзей, дети родственников или дети друзей семьи, детский коллектив на кружках — этого вполне достаточно. Годам к 10-12 дети уже начинают активно интересоваться и незнакомым окружением — тогда уже нужно давать возможность им этот интерес реализовать (и это тоже не значит «бросить в толпу, а дальше пусть попытается выплыть сам»).
В защиту «школьной социализации» возможно скажу лишь, что это пожалуй единственное место кроме семьи, в котором у детей есть возможность как-то строить отношения со сверстниками на всю жизнь (несколько лет для них это воспринимается как вся жизнь).
Я здесь не знаю насколько это важно, и у всех ли это получается, я здесь указываю на момент, который я упускаю, но который может оказаться важен (а может и не оказаться).
У тебя угнали пароли пользователей через форму входа, в чем корневая и единственная причина этого инцидента?
Если бы какой-то части обстоятельств не было (даже одного) — инцидента могло бы вообще не быть.
Похожая тема — в разборах причин автокатастроф, см википедию, там тоже так же, например: не сделали что-то здесь во время обслуживания, сломалось что-то там, совпали погодные условия, ошибка в документации на самолет (и как следствие конкретная ошибка пилота) — в результате авария. Не было бы хотя бы чего-то одного из этого — самолет нормально долетел бы резервных мощностях.
Суть похожа, конечно, но сравнивать модуляры и пюредату это как сравнивать scratch и python.
Рассказ очень интересный, но конкретно здесь — почему бы сразу продуктолога не отправить на электричках? :-)
Приблизительно то сказать наверное можно, а вот точно — очень вряд ли. Поэтому я и говорю что объективно определить цену нельзя. Хотя конечно это будет сильно зависеть от желаемой точности.
Я бы поспорил про возможность объективного определения цены для «физического устройства и потребностей клиентов», но для этого нужен контекст, а я его уже утратил.
Хотя я бы скорее не о демпинге говорил, а о распродаже товарных остатков/неликвида ниже себестоимости.
В глаза бросились несколько моментов:
* Затоваривание нехарактерно для монополии в сфере услуг. Цена на услугу у монополиста не будет падать так же как в случае с товарами. Скорее всего, это же можно сказать для товаров с ограниченным сроком хранения (например, продуктами)
* Говоря о тэта нужно говорить и о механизмах обратной связи в которых она фигурирует. Условному сборщику налогов без разницы знают его имя или нет. Ему все равно, что о нем подумают те, с кого он собирает налоги. Пока нет обратной связи — например, через закон, начальство или соседей.
Как лучше масштабировать ваш подход?
Предположим, запускается новый проект, но сразу ясно, что он будет сильно расти.
Сейчас команда маленькая, скажем 3 человека, но мы понимаем, что через год уже будет 10 человек (и это уже практически 2 команды, не одна).
А через два года 20 человек, и это уже наверняка 3-4 команды.
Проводить «смену методологии» при каждой фазе росте? Отдавать выбор методологии на откуп тимлидам? Подобрать методологию так, что можно будет ее продолжать использовать и при росте? Какой-то другой вариант?