Скорее нет, чем да. У нас специфичная работа, нужны свежие знания физики. Поэтому без опыта работы только студенты и свежеиспеченые выпускники. Ну программисты могут быть исключением.
К сожалению, некоторые «конторы» готовы таким пользоваться. Неделю потом можно премией оплатить. Это незаконно, конечно.
Если бы человек прошел собеседование у меня, то просто получил бы работу с испытательным сроком. За неделю мало чего поймешь, то же самое будет понято за собеседование.
А вот целеустремленность и умение договариваться в этой формулировке проскальзывают. Во всяком случае, это много лучше фраз в резюме в духе «я понимаю, что опыта мало, поэтому готов перерабатывать и работать за еду»
Да, это все возможные сценарии.
Я понял свою ошибку: я не рассматриваю ситуацию, когда соискатель согласен на что угодно, т.к. он только начинает карьеру.
На полтора часа я согласен. 2 — перебор.
Это действительно спорный вопрос. Например, как минимум один из собственников не разделяет моей точки зрения :)
Вопрос съема жилья поближе на студенческие оклады решается сложно.
Так что оставляю это на… совести работодателя :) Мое личное мнение: не мучить сотрудников и компанию.
Я понимаю о чем Вы. Честно говоря, я держал в голове ситуацию, когда работодатель заявляет открыто, что рассматривает и джунов.
У меня процентов 50 вакансий допускают найм студентов. Более того, дважды ко мне приходили такие студенты, что текущим сотрудником было неловко.
Более того, такой высокий процент от того, что найти спеца под ряд вакансий просто нереально. Нужно его выращивать.
В который раз убеждаюсь, что нельзя держать информацию при себе, даже если кажется, что это всем давно уже известно и очевидно.
Вроде бы статья о совершенно простых и понятных вещах, которые, казалось бы, «даже у нас» уже давно пройдены. А все равно, то тут, то там глаза цепляются за какое-то решение, за какую-то идею, которую можно попробовать.
Вот из вашей статьи выбрал для себя:
добавить статус on hold. У нас множество задач зависают в статусе «в работе» и это неудобно при анализе проекта. А статус «Отложено» используется все-таки в других ситуациях.
по какой-то необъяснимой причине мы не переводим технический долг в задачи. пора создать проект для фиксации технического долга
мы не используем скрам, скорее элементы канбана (подход к непрерывному улчшению, а не просто доска). в рамках этого подхода стендапы нужны только для того, чтобы обсудить проблемы, видимые на доске. не стоит тратить время на обсуждение того, что было сделано вчера. Ваша практика специального чата для трех вопросов может оказаться отличным решением! Так и заинтересованные лица будут видеть, кто чем занят без вчитывания в карточки на доске, так и время стендапов будет использоваться более продуктивно
также статья вдохновила меня на идею: пора в дженкинс воткнуть задачу, которая при коммите будет проверять формат комментария. И если формат нарушен — стучать емейлом по голове разработчику и его руководителю. Соглашения на словах не работают :)
отправил статью тестировщикам с пометкой «не показывать разработчикам»! :)
Потому что, с моей точки зрения, во всей статьей ключевым является параграф «Другие детали», но кто же обращает внимания на детали, когда речь зашла о том, что можно просто не исправлять баги?
Приятно видеть первый же комментарий именно на эту тему.
Но все-таки проблема о двух концах. Когда рядовые инженеры поддержки и, желательно, с помощью своих руководителей, начинают задумываться о роле IT в бизнесе, они начинают не тикеты щелкать как привыкли. а смещать акценты к реальным целям бизнеса, меняя не только методы работы, но порой и направление деятельности.
Через какое-то время вчерашний эникейщик терпеливо объясняет генеральному директору, зачем нужен CRM и как можно попробовать его внедрить, чтобы не очень больно было.
Спасибо за скрипт, использую на работе для оповещения коллег о необходимости немедленно покинуть помещение в целях проветривания :)
А можно как-то говорилке указать через какое аудио устройство воспроизводить? К сожалению, нагуглить решение может и удалось, но я этого не понял. Не силен в программировании.
Смысл задачи в том, что на устройстве две аудиокарты. Одна для скайпа по гарнитуре. Другая — «громкоговорители».
Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды. Также, отслеживая вопросы в тикетах, решенных с первого ответа, можно понять, какие статьи в базу знаний очень нужно написать, а какую инфо добавить в документацию по продукту.
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.
Вопросы problem management и knoledge management мне не дают спать уже давно :) И я был бы очень признателен, если бы Вы поделились опытом и примерами.
Еще некоторые мысли и вопросы:
Интересная у вас метрика — QA. Подумаю на досуге. Мы делаем то же самое, но не ставим оценки. И, вероятно, зря, интегральной картины и динамики -то нет.
Но с другой стороны, динамику и интегральную картину мы получаем для оценки качества все из того же FCR, Количества сообщений в рамках одного запроса и CSAT.
Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность. Если только нужны для контроля новичков.
Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.
И главный вопрос, как, ну КАК считать все эти метрики :( Я умею пользоваться экселькой, но пользователи не хотят и не желают создавать новые тикеты для новых проблем. А очень часто отвечают на старые реквесты. В результате чего ни FCR, ни TTR посчитать корректно в автоматическом режиме не получается :(
Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.
Спасибо за интересную статью! И успехов в делах :)
У меня есть WD mybooklive. С ним что-то случилось и он не грузится (светит светодиодом, информируя о проблеме загрузки оси). Замена диска и перепрошивка не помогли. Может с ним и все ок, просто я где-то накосячил. Но в итоге было куплено устройство другого уровня (мне только дай повод :) ). А трупик WD планирую выкинуть. Но если автор статьи обитает в Москве и ему эта тушка была бы полезна, могу отдать безвозмездно.
Спасибо за статью. Отдал почитать сотрудникам, убрав вторую часть девятого пункта, про однозначность.
Хочу немного рассказать о причинах:
У нас команда разрабатывает тестирует и поддерживает крайне сложный программный продукт с невероятным количеством объектов. Доходит до того, что на этапе тестирования всплывает одинаковое именование совершенно разных объектов (очевидно, что эта проблема должна решаться не на этапе тестирования, а организационными методами, но сейчас не об этом).
Мы столкнулись со следующей проблемой:
в команде, естественно, сложился свой жаргон. Очень часто жаргонизмы рождаются на этапе становления проекта, когда вот эту штуку, которую еще толком не спроектировали, уже нужно как-то называть. Вот и рождаются всякие ППП, ОБЛ, Химеры, Толерансы, g-точки и прочие звери. Лишь в момент реализации интерфейсов звери обретают более благородные имена, которые закрепляются документацией.
А теперь представьте, что не только разработчики, но и тестировщики, и техподдержка смертельно заражены этой жаргонной заразой. Вот в этот момент понимаешь, что «аккумуляторная батарея питания» — это однозначная, всем понятная языковая единица, а «батарейка» — это любимая песня тестировщика.
Мы столкнулись с реальной проблемой при транслировании ошибки от пользователей через техподдержку к разработчикам и далее к тестировщикам. Когда из-за неоднозначных трактовок, терминов, обозначающих сразу множество элементов программы, сотрудники из разных групп начинали терять время. THIS IS BABYLON!
А еще, жаргонизмы — ужасные слова паразиты, которые моментально начинают лезть как тараканы в письма от техподдержки к клиентам, последствия чего проиллюстрированы первой картинкой в топике.
Посмотрев на все это было принято решение бичевать сотрудников за употребление даже самых безобидных сокращений и жаргонизмов при оформлении багов ошибок.
Чисто субъективно, создается ощущение, что культура документального общения, только благодаря жесткой дисциплине в команде техподдержки, сама собой стала расти во всех остальных командах. При этом, никаких жалоб на оформляемые багрепорты не поступало, всем все было понятно, и разработчиков никто не просил ничего ломать в их хрупком мировосприятии.
PS кстати, g-точка в интерфейсе осталась g-точкой. Я был бы не против еще и Химеры, это прибавило бы немного эпичности нашему программному продукту.
Подскажите, пожалуйста, почему по оси амплитуд на диаграммах амплитудного спектра значение этих самых амплитуд как-то, мягко говоря, не очень похоже на амплитуды, которые содержит исходный сигнал? Как правило, амплитуда на амплитудном спектре существенно (на порядки) выше амплитуды исходного сигнала, если смотреть на pdf с примерами.
Я полагаю, здесь достаточно простой ответ из области математики. Просто я от этой области далек. Может кто подскажет?
Автору спасибо за статью!
Белый текст на светло-салатовом фоне — это недоработка в плане интерфейса :)
Я попытался исправить CSS файл, после рестарта apache, редмайн падает в плагине при подгрузке этого CSS. Ума не приложу, почему. не программист. с точки зрения css все корректно.
Скорее нет, чем да. У нас специфичная работа, нужны свежие знания физики. Поэтому без опыта работы только студенты и свежеиспеченые выпускники. Ну программисты могут быть исключением.
Если бы человек прошел собеседование у меня, то просто получил бы работу с испытательным сроком. За неделю мало чего поймешь, то же самое будет понято за собеседование.
А вот целеустремленность и умение договариваться в этой формулировке проскальзывают. Во всяком случае, это много лучше фраз в резюме в духе «я понимаю, что опыта мало, поэтому готов перерабатывать и работать за еду»
Я понял свою ошибку: я не рассматриваю ситуацию, когда соискатель согласен на что угодно, т.к. он только начинает карьеру.
Я вполне допускаю, что мой взгляд на вопрос двух часов-это повод обходить меня, как работодателя.
Возможно я дал вредный совет. Пожалуй, я сделаю ремарку в тексте на этот счет. Спасибо
Это действительно спорный вопрос. Например, как минимум один из собственников не разделяет моей точки зрения :)
Вопрос съема жилья поближе на студенческие оклады решается сложно.
Так что оставляю это на… совести работодателя :) Мое личное мнение: не мучить сотрудников и компанию.
У меня процентов 50 вакансий допускают найм студентов. Более того, дважды ко мне приходили такие студенты, что текущим сотрудником было неловко.
Более того, такой высокий процент от того, что найти спеца под ряд вакансий просто нереально. Нужно его выращивать.
Вроде бы статья о совершенно простых и понятных вещах, которые, казалось бы, «даже у нас» уже давно пройдены. А все равно, то тут, то там глаза цепляются за какое-то решение, за какую-то идею, которую можно попробовать.
Вот из вашей статьи выбрал для себя:
Потому что, с моей точки зрения, во всей статьей ключевым является параграф «Другие детали», но кто же обращает внимания на детали, когда речь зашла о том, что можно просто не исправлять баги?
Спасибо за материал!
Но все-таки проблема о двух концах. Когда рядовые инженеры поддержки и, желательно, с помощью своих руководителей, начинают задумываться о роле IT в бизнесе, они начинают не тикеты щелкать как привыкли. а смещать акценты к реальным целям бизнеса, меняя не только методы работы, но порой и направление деятельности.
Через какое-то время вчерашний эникейщик терпеливо объясняет генеральному директору, зачем нужен CRM и как можно попробовать его внедрить, чтобы не очень больно было.
Изменения возможны снизу.
А можно как-то говорилке указать через какое аудио устройство воспроизводить? К сожалению, нагуглить решение может и удалось, но я этого не понял. Не силен в программировании.
Смысл задачи в том, что на устройстве две аудиокарты. Одна для скайпа по гарнитуре. Другая — «громкоговорители».
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.
Вопросы problem management и knoledge management мне не дают спать уже давно :) И я был бы очень признателен, если бы Вы поделились опытом и примерами.
Еще некоторые мысли и вопросы:
Интересная у вас метрика — QA. Подумаю на досуге. Мы делаем то же самое, но не ставим оценки. И, вероятно, зря, интегральной картины и динамики -то нет.
Но с другой стороны, динамику и интегральную картину мы получаем для оценки качества все из того же FCR, Количества сообщений в рамках одного запроса и CSAT.
Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность. Если только нужны для контроля новичков.
Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.
И главный вопрос, как, ну КАК считать все эти метрики :( Я умею пользоваться экселькой, но пользователи не хотят и не желают создавать новые тикеты для новых проблем. А очень часто отвечают на старые реквесты. В результате чего ни FCR, ни TTR посчитать корректно в автоматическом режиме не получается :(
Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.
Спасибо за интересную статью! И успехов в делах :)
Хочу немного рассказать о причинах:
У нас команда разрабатывает тестирует и поддерживает крайне сложный программный продукт с невероятным количеством объектов. Доходит до того, что на этапе тестирования всплывает одинаковое именование совершенно разных объектов (очевидно, что эта проблема должна решаться не на этапе тестирования, а организационными методами, но сейчас не об этом).
Мы столкнулись со следующей проблемой:
в команде, естественно, сложился свой жаргон. Очень часто жаргонизмы рождаются на этапе становления проекта, когда вот эту штуку, которую еще толком не спроектировали, уже нужно как-то называть. Вот и рождаются всякие ППП, ОБЛ, Химеры, Толерансы, g-точки и прочие звери. Лишь в момент реализации интерфейсов звери обретают более благородные имена, которые закрепляются документацией.
А теперь представьте, что не только разработчики, но и тестировщики, и техподдержка смертельно заражены этой жаргонной заразой. Вот в этот момент понимаешь, что «аккумуляторная батарея питания» — это однозначная, всем понятная языковая единица, а «батарейка» — это любимая песня тестировщика.
Мы столкнулись с реальной проблемой при транслировании ошибки от пользователей через техподдержку к разработчикам и далее к тестировщикам. Когда из-за неоднозначных трактовок, терминов, обозначающих сразу множество элементов программы, сотрудники из разных групп начинали терять время. THIS IS BABYLON!
А еще, жаргонизмы — ужасные слова паразиты, которые моментально начинают лезть как тараканы в письма от техподдержки к клиентам, последствия чего проиллюстрированы первой картинкой в топике.
Посмотрев на все это было принято решение бичевать сотрудников за употребление даже самых безобидных сокращений и жаргонизмов при оформлении
баговошибок.Чисто субъективно, создается ощущение, что культура документального общения, только благодаря жесткой дисциплине в команде техподдержки, сама собой стала расти во всех остальных командах. При этом, никаких жалоб на оформляемые багрепорты не поступало, всем все было понятно, и разработчиков никто не просил ничего ломать в их хрупком мировосприятии.
PS кстати, g-точка в интерфейсе осталась g-точкой. Я был бы не против еще и Химеры, это прибавило бы немного эпичности нашему программному продукту.
Длина сигнала в данном случае — это в секундах или в числе дискретных отрезков?
Я полагаю, здесь достаточно простой ответ из области математики. Просто я от этой области далек. Может кто подскажет?
Автору спасибо за статью!
Боюсь что нет. Около 5% пользователей попросили сделать цифру читаемой (остальным, подозреваю, просто не до грибов).
Вот сравнение:
Как видно, Во втором случае цифра более читаемая.
Я попытался исправить CSS файл, после рестарта apache, редмайн падает в плагине при подгрузке этого CSS. Ума не приложу, почему. не программист. с точки зрения css все корректно.