Немного цифр сделало бы статью более полной: сколько людей в год ищете и в итоге нанимаете.
А ещё интересно, как вы из сообществ интересных кандидатов вытаскиваете - только тех, кто резюме постит, или как-то выбираете, с кем говорить. Сообщества и чаты, посвященные DevOps кажется вчера и сегодня обречены превращаться в склад вакансий, где всем надо, а релевантных откликов единицы. В DevSecOps ситуация похожа?
Ууу... Спасибо за ваш комментарий с переходом на личности.
Отвечу кратко: ваши кейсы жизнеспособны и возможны. Так же, как возможны и приведенные мной кейсы - чего только не происходит в реальной жизни. Я резюмирую двумя абзацами вывод, который пытаюсь донести уже третий коммент:
Вы можете очень много работать, но это в реальной компании (любая "реальная компания" = неидеальные процессы) может не нести никакой дополнительной ценности для вашего руководителя и компании. И даже если вам кажется, что вы очень хорошо делаете свою работу, это не значит, что так думает ваш руководитель и это приносит компании деньги. Именно поэтому важно верифицировать свои активности, а не просто пахать.
Может ли получиться, что без верификации ваши активности и работа 24/7 принесут пользу компании и будут оценены? Может. Может случиться, что не будут оценены? Может. Но если вы будете свои активности и их необходимость заранее верифицировать и согласовывать с целями руководителя и компании, то вероятность, что будете оценены - больше.
По этому топику у меня всё. Ваши домыслы о моих компетенциях, о том, что мне понятно, а что нет, безусловно, занимательны, но предмета обсуждения они не составляют.
Представьте себя на месте руководителя этого человека: у вас ответственный проект, вы собираете все ресурсы для достижения результата в срок, а тут вот такие выходки.
Ок, сейчас он пришел к вам в сильной позиции и в моменте вероятно получит, что просит. Будете ли вы рассчитывать на такого человека в следующий раз? Будете ли вы склонны при распределении бонусов от проекта (ограниченный ресурс) дать что-то ему? Чо будете делать, если на следующем проекте он повторит свой маневр?
Как раз чтобы не был позитивного подкрепления кейса, что таким образом можно что-то получить, и корабль не рассыпался на пол пути, зачастую даже намеки на такие действия пресекаются: лучше тут что-то управляемо перетерпеть, чем развалить всю систему, когда она пойдет в разнос.
Мы статью обсуждаем, или что? Там про "пчёлок" в терминах автора два абзаца. Одним предложением: "пчёлка много работает, но не факт, что приносит видимую ценность".
Не нравится про чайники, пожалуйста, на ваших примерах:
если человек сверхурочно поработал и договорился о поставках товара в условную Боливию? Хотя мог встать и уйти в 6 часов, но вместо этого принёс компании Н миллионов? С ним можно поделиться?
А утром производство узнало об этой договоренности, и не нашло нематерных слов, потому что поставки необходимого для производства компонента будут только через месяц после даты отгрузки по контракту. А финики сказали, что если случится выручка на Н миллионов, то компания потеряет право на льготу и будет вынуждена заплатить 2Н миллионов налогов.
Или закупщик большой продуктовой сети, прочухал ожидаемый кризис с сахаром и гречкой и задержавшись на работе успел подписать пару контрактов на поставки до подорожания, а после товар сметают с полок. Он молодец? С ним можно поделиться?
Молодец, взял на себя риски, заработал денег компании. Но если руководитель не знает, что он это сделал, то эти два контракта потеряются в стопятьсоттысячдва контрактах, которые подписывает служба закупок за месяц.
А если разработчик неделю сидел ночами и отрефакторил к чертям бекенд, да так, что билд стал собираться в 2 раза быстрее, а сам код в процессе исполнения отжирать на 10% меньше памяти, что позволит не только быстрее доставлять обновления, но экономить на мощностях? С ним можно поделиться?
Может и молодец, только вот ресурсов было с избытком и 10% памяти не дало никакой экономии в деньгах. А билд хоть в 10 раз быстрее сделай, там автотесты работают в 100 раз дольше, чем он до этого собирался.
Лучше бы он не выгорел, и фичу новую сделал за день, а не тупил неделю.
Вопрос не в примере, вопрос в том, принес ли он ценность. Об этом автор статьи и пишет в двух абзацах на тему "пчёлок". Сотруднику может казаться, что его действия - это безусловная ценность, а если бы он верифицировал ее с руководителем, то сделал бы что-то другое, действительно полезное, а не полезное на его взгляд. Верифицировать свои цели - это более гарантированный способ заявить о своей ценности.
Говорю вам, как руководитель - если не может и не хочет, ему пора с должности. Иначе вообще не понятно, зачем он на ней существует. Обязанность руководителя в планировании и распределении нагрузки.
Говорю вам как руководитель - есть момент, когда ты реально не можешь знать, что там кто когда делает, только в общих чертах. И не хочешь, потому что погружаться - это путь к микроменеджменту. Обязанности руководителя зачастую куда шире, чем планирование и распределение нагрузки. А вот есть ли ценность от подразделения/сотрудника вполне видно. По PL, отзывам Заказчика, T2M, у каждого свое. И это ещё раз говорит о необходимости верифицировать цели и ценность, прежде чем пахать.
В большинстве случаев риски поиска нового сотрудника значительно выше и значительно затратнее. Если вы хоть когда-то искали хоть кого-то, то можете знать об этом.
В целом, да, а в частностях - нет. Найти кассира вместо текущего токсичного и научить, не рокет сайнс и не слишком затратно по найму и онбордингу. В ИТшной среде, да, порог выше, онбординг сложнее, рынок выжат. Но общая логика и тут работает: чем больше субъективная оценка отношения "приносимая ценность/приносимые проблемы", тем больше есть желание сотрудника оставить. Если сотрудник приходит каждые три месяца с офером, требует повышения, и ноет в коллективе, какие низкие зарплаты в компании, то знаменатель резко начинает перевешивать. При том перевешивать все затраты на найм и онбординг.
Показывать реальный офер - это не шантаж, если вы готовы уйти. Эта ваша готовность и отличает торг от шантажа.
Если вы придёте, и скажете, я бы очень хотел дальше работать тут , но деньги сейчас для меня важно, и я буду вынужден уйти, если не смогу через Х месяцев получать вот такую сумму (и тут офер вполне аргумент вашей рыночной ценности, можно и показать), давайте составим план, что нужно сделать, чтобы это стало возможным - это будет вход в диалог.
Но не факт, что результатом этого диалога будет положительное решение - вам по разным причинам, от политики компании, до мнения о вас руководителя, могут и сказать, что найти такие условия здесь нереально и отпустить.
В моей практике есть кейс, когда я не могу удовлетворить амбицию человека по росту, и предложил уйти и искать возможность удовлетворения на рынке. Да, обидно, вырастили и потеряли, но так бывает. К сожалению, кейсов, когда приходят с реальным намерением и честным диалогом и желанием что-то изменить в себе и остаться в разы (кажется, что почти на порядок) меньше, чем кейсов, когда приходят с офером и заявкой, мол буду делать тоже что делал раньше, но хочу больше денег. И даже кейсов, что готовы были отпустить, но человек оставался без удовлетворения своего запроса, больше, чем кейсов, когда человек в итоге ушел.
Если человек выполняет какую то работу, через время он начинает выполнять эту работу эффективнее. Т.е. приносить больше прибавочного продукта в единицу времени. Может быть, это справедливо - немного поделиться с этим человеком?
Даже если он и делает работу больше/лучше, то это совсем не повод ему что-то повышать. Во-первых, потому что не факт, что больше нужно. Рассмотрим на простом примере: предприятие делает чайники. Один слесарь делает саму форму, а второй крышечку. Если один из них станет делать в два раза больше, это не значит, что компания станет продавать в два раза больше чайников. Как минимум не будет комплиментарной части, а может и спроса на рынке нет, и больше просто не надо.
Это точно руководитель? Чем он занимается, если нужно аргументировать чем сотрудник занят на работе? С рыночной ценой это вообще 5 балов. Полагаю, после такого нужно сразу идти искать вменяемого руководителя.
Это точно руководитель.Руководитель не хочет, и, зачастую, не может знать, что именно делают его сотрудники. Зато он знает про ценность, которую вы приносите подразделением или индивидуально. И именно об этой ценности и нужно говорить, руководитель может сориентировать, как именно вы можете приносить больше ценности ему и/или компании. Про минусы ваши, он тоже знает, и не факт, что он захочет дать вам текущую рыночную стоимость с учётом этого, а не попытать удачу, потратившись на найм нового человека. В этом же и ответ на вопрос про "прикол потратиться на найм" - иногда лучше потратиться, чем принять риски дальнейшего сотрудничества.
Можно сопротивляться, но оно действительно работает так, как написано в статье.
Термин уже лет 5 как широко в ходу, во всяком случае, я его в среде слышу точно не меньше - видимо, прижился.
Но давайте будем честны, это и по сути своей не новая роль. Как-то надо было назвать ИТ-шного РПшника, точнее "РПшника в сфере разработки ПО" - вот, это он, Delivery manager.
Термин "Руководитель проекта" был не подходящим и ломал шаблоны в головах, так как вроде и проекта нет как ограниченного во времени предприятия с уникальным результатом, а есть регулярная производственная деятельность. Поэтому группы процессов PMBOKовские слабо получалось применять, не делать же, в самом деле, устав на каждый спринт. А вот зона ответственности за сроки, стоимость, объем и качество, и области знаний все те же, РПшные.
И сколько позиций, если не секрет удалось закрыть за год (или за период, в которой работает все описанное)? Сколько времени занимало закрытие позиций и сколько занимает теперь?
То чувство, когда узнал, что Kanban это что-то между скрамом и водопадом и совсем не Agile. Картинка получилась красивой, но вообще говоря, Kanban более гибкий чем Scrum, и хорош, когда ты даже на спринт запланировать не можешь.
А тезис заложен хороший - когда простая мысль, что для каждого кейса хорош свой инструмент, который поможет выбрать грамотный PM, и не надо везде пихать Scrum, наконец осядет в головах широкой общественности (Заказчика), мир станет чуточку лучше.
Дальше просто берите билеты с запасом в один день в начале поездки (чтобы приехать из аэропорта и принять лодку, ночевать лучше сразу на ней в марине), и ещё 2–3 дня запаса заложите в конце. Потому что переходы по воде не очень хорошо предсказываются из-за изменений ветра, и планируемая дата возвращения и сдачи лодки может отличаться от фактической.
Чартерная неделя всегда заканчивается вечером предыдущего сдаче лодке дня, ибо приемка лодки у шкипера происходит вечером. Обычно, лодка берется с субботы по субботу, т.е. в субботу будет приемка лодки (обычно до вечера), а в пятницу до заката лодку нужно уже сдать.
В прочем, это детали. Статья отличная для тех, кто думал о море, но еще не ходил. Главное, ищите шкипера, которому доверяете, ибо надо помнить, что на лодке все окончательные решения будут за шкипером, а детали про билеты и всё прочее он вам подскажет.
Хождение не в море помошает очень слабо. Просто посмотреть и попробовать — взять лодку на пару часов классная тема, но морская болезнь будет в море, а не на ровной воде.
Сильно зависит от погоды. Но если будет комфортный для хождения ветер, первые два дня будет клонить в сон и не хотеться есть, потом привыкнете.
А вот если в какой-то момент будет штормить, то вероятность попрощаться с обедом в этот момент стремится к 100% для любого не ходящего по морю постоянно человека.
Итого: провести серо-зеленым все время маловероятно — будет пара неприятных моментов или дней. Но также маловероятно, что участь морской болезни вас минует.
Спасибо. Это правильнее назвать единое хранилище данных ИАС МКР (Информационно-аналитическая система мониторинга комплексного развития города Москвы). Хотя система, безусловно, правительства Москвы.
putnik, как указано на сайте data.mos.ru внизу страницы, данные распространяются по лицензии Creative Commons Attribution 3.0 — вполне себе международной. Ни о каких «законных целях» речи не идет, и открытые проекты, и бизнес их вполне могут использовать. Искажение, действительно, запрещено, но никто не запрещает перерабатывать (в терминах лицензии «Адаптировать») данные и использовать для своих целей, не апеллируя при этом к первоисточнику.
Такая же лицензия используется на большинстве порталов регионов: opendata.permkrai.ru, www.opendata71.ru…
P.S. Представителей IT-сообщества на заседании было достаточно много, и разумеется, именно они и занимаются поддержкой открытых данных. Если есть конкретные предложения по открытым данным Москвы, то им будут рады по адресу opendata@mos.ru — знаю лично людей, которые обрабатывают эти обращения, они вполне адекватные, имеют прямой доступ к принимающим решения по порталу открытых данных, отвечают на все обращения и стараются учесть все поступающие конструктивные предложения.
Вопросы юзабилити всегда неоднозначны, но что касательно поля «Промо-код» и кнопки «Применить» вопрос уж совсем спорный.
Ситуация 1: Пользователь вводит промо-код и нажимает «Применить»
Ожидаемая реакция: корзина пересчитается с учетом промо-кода. При этом пользователю всё равно, что произойдет со страницей: обновится, не обновится, лишь бы скидку дали.
Ситуация 2: пользователь вводит промо-код, а кнопки применить нет.
Ожидаемая реакция А: корзина пересчитается сразу после ввода последнего символа;
Ожидаемая реакция B: корзина пересчитается сразу после ввода и снятия фокуса с поля;
Ожидаемая реакция C: корзина пересчитается после ввода кода и нажатия кнопки «Заказать».
Т.е. что должно случиться однозначно непонятно.
В итоге отсутствие кнопки имеет для бизнеса негативные последствия, например. если промо-код не применяется, а такое бывает нередко: или промо-код нерабочий, или введен неправильно, а клиент решил не замечать красной надписи об ошибке. В итоге клиент оказывается недоволен, заказ отменен, что хуже — возвращен из-за несоответствия цены ожиданиям, в особо лютых случаях клиенты начинают требовать скидку по промо-коду у курьера. А это уже совсем другие показатели, более важные, чем конверсия.
У одного брендового магазина пока проверяется промо-код, вообще можно вполне успеть нажать «Заказать», и заказ оформляется без применения промо-кода.
Так что, кнопку «Применить» убирать стоит кране осмотрительно.
Залить диэлектриком железку под напряжением — в теории ничего страшного. Физики разрешают. =) Но исходя из техники безопасности, я бы предварительно напряжение-то отключил.
А медики присвоят класс опасности, и небольшое гугление подсказывает, что класс опасности будет IV (минимальный) или вообще вещество как опасное не будет классифицироваться. Будет надпись «При попадании в дыхательные пути или проглатывании обратитесь к врачу» как на бытовой химии. Вряд ли нюхнуть химически малоактивный гидрофторэфир хуже, чем нанюхаться соединений хлора из какой-нибудь бытовой химии или любого эфиросодержащего растворителя.
Для вытеснения воды иметь, конечно, здорово. Столько ноутов похоронили из-за того, что проливали на них разнообразные напитки, а возможности оперативно прочистить не было.
Для очистки от пыли вопрос только в цене. Если сравнимо со стоимостью баллончика со сжатым воздухом — может пользоваться популярностью. Если дороже — то остается смысл применять только в сильнозагрязненных местах, где нужно именно промыть, а продув не катит.
Немного цифр сделало бы статью более полной: сколько людей в год ищете и в итоге нанимаете.
А ещё интересно, как вы из сообществ интересных кандидатов вытаскиваете - только тех, кто резюме постит, или как-то выбираете, с кем говорить. Сообщества и чаты, посвященные DevOps кажется вчера и сегодня обречены превращаться в склад вакансий, где всем надо, а релевантных откликов единицы. В DevSecOps ситуация похожа?
Ууу... Спасибо за ваш комментарий с переходом на личности.
Отвечу кратко: ваши кейсы жизнеспособны и возможны. Так же, как возможны и приведенные мной кейсы - чего только не происходит в реальной жизни. Я резюмирую двумя абзацами вывод, который пытаюсь донести уже третий коммент:
Вы можете очень много работать, но это в реальной компании (любая "реальная компания" = неидеальные процессы) может не нести никакой дополнительной ценности для вашего руководителя и компании. И даже если вам кажется, что вы очень хорошо делаете свою работу, это не значит, что так думает ваш руководитель и это приносит компании деньги. Именно поэтому важно верифицировать свои активности, а не просто пахать.
Может ли получиться, что без верификации ваши активности и работа 24/7 принесут пользу компании и будут оценены? Может. Может случиться, что не будут оценены? Может. Но если вы будете свои активности и их необходимость заранее верифицировать и согласовывать с целями руководителя и компании, то вероятность, что будете оценены - больше.
По этому топику у меня всё. Ваши домыслы о моих компетенциях, о том, что мне понятно, а что нет, безусловно, занимательны, но предмета обсуждения они не составляют.
Это как раз чистой воды манипуляция.
Представьте себя на месте руководителя этого человека: у вас ответственный проект, вы собираете все ресурсы для достижения результата в срок, а тут вот такие выходки.
Ок, сейчас он пришел к вам в сильной позиции и в моменте вероятно получит, что просит. Будете ли вы рассчитывать на такого человека в следующий раз? Будете ли вы склонны при распределении бонусов от проекта (ограниченный ресурс) дать что-то ему? Чо будете делать, если на следующем проекте он повторит свой маневр?
Как раз чтобы не был позитивного подкрепления кейса, что таким образом можно что-то получить, и корабль не рассыпался на пол пути, зачастую даже намеки на такие действия пресекаются: лучше тут что-то управляемо перетерпеть, чем развалить всю систему, когда она пойдет в разнос.
Мы статью обсуждаем, или что? Там про "пчёлок" в терминах автора два абзаца. Одним предложением: "пчёлка много работает, но не факт, что приносит видимую ценность".
Не нравится про чайники, пожалуйста, на ваших примерах:
А утром производство узнало об этой договоренности, и не нашло нематерных слов, потому что поставки необходимого для производства компонента будут только через месяц после даты отгрузки по контракту. А финики сказали, что если случится выручка на Н миллионов, то компания потеряет право на льготу и будет вынуждена заплатить 2Н миллионов налогов.
Молодец, взял на себя риски, заработал денег компании. Но если руководитель не знает, что он это сделал, то эти два контракта потеряются в стопятьсоттысячдва контрактах, которые подписывает служба закупок за месяц.
Может и молодец, только вот ресурсов было с избытком и 10% памяти не дало никакой экономии в деньгах. А билд хоть в 10 раз быстрее сделай, там автотесты работают в 100 раз дольше, чем он до этого собирался.
Лучше бы он не выгорел, и фичу новую сделал за день, а не тупил неделю.
Вопрос не в примере, вопрос в том, принес ли он ценность. Об этом автор статьи и пишет в двух абзацах на тему "пчёлок". Сотруднику может казаться, что его действия - это безусловная ценность, а если бы он верифицировал ее с руководителем, то сделал бы что-то другое, действительно полезное, а не полезное на его взгляд. Верифицировать свои цели - это более гарантированный способ заявить о своей ценности.
Говорю вам как руководитель - есть момент, когда ты реально не можешь знать, что там кто когда делает, только в общих чертах. И не хочешь, потому что погружаться - это путь к микроменеджменту. Обязанности руководителя зачастую куда шире, чем планирование и распределение нагрузки. А вот есть ли ценность от подразделения/сотрудника вполне видно. По PL, отзывам Заказчика, T2M, у каждого свое. И это ещё раз говорит о необходимости верифицировать цели и ценность, прежде чем пахать.
В целом, да, а в частностях - нет. Найти кассира вместо текущего токсичного и научить, не рокет сайнс и не слишком затратно по найму и онбордингу. В ИТшной среде, да, порог выше, онбординг сложнее, рынок выжат. Но общая логика и тут работает: чем больше субъективная оценка отношения "приносимая ценность/приносимые проблемы", тем больше есть желание сотрудника оставить. Если сотрудник приходит каждые три месяца с офером, требует повышения, и ноет в коллективе, какие низкие зарплаты в компании, то знаменатель резко начинает перевешивать. При том перевешивать все затраты на найм и онбординг.
Показывать реальный офер - это не шантаж, если вы готовы уйти. Эта ваша готовность и отличает торг от шантажа.
Если вы придёте, и скажете, я бы очень хотел дальше работать тут , но деньги сейчас для меня важно, и я буду вынужден уйти, если не смогу через Х месяцев получать вот такую сумму (и тут офер вполне аргумент вашей рыночной ценности, можно и показать), давайте составим план, что нужно сделать, чтобы это стало возможным - это будет вход в диалог.
Но не факт, что результатом этого диалога будет положительное решение - вам по разным причинам, от политики компании, до мнения о вас руководителя, могут и сказать, что найти такие условия здесь нереально и отпустить.
В моей практике есть кейс, когда я не могу удовлетворить амбицию человека по росту, и предложил уйти и искать возможность удовлетворения на рынке. Да, обидно, вырастили и потеряли, но так бывает. К сожалению, кейсов, когда приходят с реальным намерением и честным диалогом и желанием что-то изменить в себе и остаться в разы (кажется, что почти на порядок) меньше, чем кейсов, когда приходят с офером и заявкой, мол буду делать тоже что делал раньше, но хочу больше денег. И даже кейсов, что готовы были отпустить, но человек оставался без удовлетворения своего запроса, больше, чем кейсов, когда человек в итоге ушел.
Даже если он и делает работу больше/лучше, то это совсем не повод ему что-то повышать. Во-первых, потому что не факт, что больше нужно. Рассмотрим на простом примере: предприятие делает чайники. Один слесарь делает саму форму, а второй крышечку. Если один из них станет делать в два раза больше, это не значит, что компания станет продавать в два раза больше чайников. Как минимум не будет комплиментарной части, а может и спроса на рынке нет, и больше просто не надо.
Это точно руководитель.Руководитель не хочет, и, зачастую, не может знать, что именно делают его сотрудники. Зато он знает про ценность, которую вы приносите подразделением или индивидуально. И именно об этой ценности и нужно говорить, руководитель может сориентировать, как именно вы можете приносить больше ценности ему и/или компании. Про минусы ваши, он тоже знает, и не факт, что он захочет дать вам текущую рыночную стоимость с учётом этого, а не попытать удачу, потратившись на найм нового человека. В этом же и ответ на вопрос про "прикол потратиться на найм" - иногда лучше потратиться, чем принять риски дальнейшего сотрудничества.
Можно сопротивляться, но оно действительно работает так, как написано в статье.
Термин уже лет 5 как широко в ходу, во всяком случае, я его в среде слышу точно не меньше - видимо, прижился.
Но давайте будем честны, это и по сути своей не новая роль. Как-то надо было назвать ИТ-шного РПшника, точнее "РПшника в сфере разработки ПО" - вот, это он, Delivery manager.
Термин "Руководитель проекта" был не подходящим и ломал шаблоны в головах, так как вроде и проекта нет как ограниченного во времени предприятия с уникальным результатом, а есть регулярная производственная деятельность. Поэтому группы процессов PMBOKовские слабо получалось применять, не делать же, в самом деле, устав на каждый спринт. А вот зона ответственности за сроки, стоимость, объем и качество, и области знаний все те же, РПшные.
И сколько позиций, если не секрет удалось закрыть за год (или за период, в которой работает все описанное)? Сколько времени занимало закрытие позиций и сколько занимает теперь?
То чувство, когда узнал, что Kanban это что-то между скрамом и водопадом и совсем не Agile. Картинка получилась красивой, но вообще говоря, Kanban более гибкий чем Scrum, и хорош, когда ты даже на спринт запланировать не можешь.
А тезис заложен хороший - когда простая мысль, что для каждого кейса хорош свой инструмент, который поможет выбрать грамотный PM, и не надо везде пихать Scrum, наконец осядет в головах широкой общественности (Заказчика), мир станет чуточку лучше.
Чартерная неделя всегда заканчивается вечером предыдущего сдаче лодке дня, ибо приемка лодки у шкипера происходит вечером. Обычно, лодка берется с субботы по субботу, т.е. в субботу будет приемка лодки (обычно до вечера), а в пятницу до заката лодку нужно уже сдать.
В прочем, это детали. Статья отличная для тех, кто думал о море, но еще не ходил. Главное, ищите шкипера, которому доверяете, ибо надо помнить, что на лодке все окончательные решения будут за шкипером, а детали про билеты и всё прочее он вам подскажет.
А вот если в какой-то момент будет штормить, то вероятность попрощаться с обедом в этот момент стремится к 100% для любого не ходящего по морю постоянно человека.
Итого: провести серо-зеленым все время маловероятно — будет пара неприятных моментов или дней. Но также маловероятно, что участь морской болезни вас минует.
А что это за «единое хранилище данных правительства Москвы» и где можно посмотреть, что там опубликовано?
Такая же лицензия используется на большинстве порталов регионов: opendata.permkrai.ru, www.opendata71.ru…
P.S. Представителей IT-сообщества на заседании было достаточно много, и разумеется, именно они и занимаются поддержкой открытых данных. Если есть конкретные предложения по открытым данным Москвы, то им будут рады по адресу opendata@mos.ru — знаю лично людей, которые обрабатывают эти обращения, они вполне адекватные, имеют прямой доступ к принимающим решения по порталу открытых данных, отвечают на все обращения и стараются учесть все поступающие конструктивные предложения.
Ситуация 1: Пользователь вводит промо-код и нажимает «Применить»
Ожидаемая реакция: корзина пересчитается с учетом промо-кода. При этом пользователю всё равно, что произойдет со страницей: обновится, не обновится, лишь бы скидку дали.
Ситуация 2: пользователь вводит промо-код, а кнопки применить нет.
Ожидаемая реакция А: корзина пересчитается сразу после ввода последнего символа;
Ожидаемая реакция B: корзина пересчитается сразу после ввода и снятия фокуса с поля;
Ожидаемая реакция C: корзина пересчитается после ввода кода и нажатия кнопки «Заказать».
Т.е. что должно случиться однозначно непонятно.
В итоге отсутствие кнопки имеет для бизнеса негативные последствия, например. если промо-код не применяется, а такое бывает нередко: или промо-код нерабочий, или введен неправильно, а клиент решил не замечать красной надписи об ошибке. В итоге клиент оказывается недоволен, заказ отменен, что хуже — возвращен из-за несоответствия цены ожиданиям, в особо лютых случаях клиенты начинают требовать скидку по промо-коду у курьера. А это уже совсем другие показатели, более важные, чем конверсия.
У одного брендового магазина пока проверяется промо-код, вообще можно вполне успеть нажать «Заказать», и заказ оформляется без применения промо-кода.
Так что, кнопку «Применить» убирать стоит кране осмотрительно.
А медики присвоят класс опасности, и небольшое гугление подсказывает, что класс опасности будет IV (минимальный) или вообще вещество как опасное не будет классифицироваться. Будет надпись «При попадании в дыхательные пути или проглатывании обратитесь к врачу» как на бытовой химии. Вряд ли нюхнуть химически малоактивный гидрофторэфир хуже, чем нанюхаться соединений хлора из какой-нибудь бытовой химии или любого эфиросодержащего растворителя.
Для очистки от пыли вопрос только в цене. Если сравнимо со стоимостью баллончика со сжатым воздухом — может пользоваться популярностью. Если дороже — то остается смысл применять только в сильнозагрязненных местах, где нужно именно промыть, а продув не катит.
itunes.apple.com/ru/app/microsoft-excel-dla-ipad/id586683407?mt=8 — Excel
itunes.apple.com/ru/app/microsoft-powerpoint-dla-ipad/id586449534?mt=8 — PowerPoint
Для жаждущих ссылок:
Word
Excel
PowerPoint