leanoffice, поясните, пожалуйста, что вы понимаете под рефреймингом резюме в описанном этапе? Правильно я понимаю, что это при наличие информации о ящике потенциального работодателя: то есть отправляется версий, например, doc-файла резюме с акцентами на необходимом ему опыт? Как поступили бы при рабоче через тот же HH: посоветуете своему другу создавать каждый раз новое резюме в профиле или же расставить акценты уже в сопроводительном письме?
Понимаю, что этом мелочи этапа, но тем не менее.
Чек-лист незаменим там, где каждый пропущенный чек-бокс означает неработающий сервис. Вот именно так у пилотов, приведенных в пример в статье.
Например, если пропущен пункт sftp, не сконфигурирован sftp-порт — не запустится резервирование журналов; если не внесены параметры в ветку реестра «x», то профиль оборудования не отразится в мониторинге.
Таким образом, каждый пункт листа должен быть отмечен, иначе проверка не пройдена, не завершена.
В противном случае, это лишь пункты списка и требуют других инструментов в работе, например, Ту-ду лист с возможностью переноса в другую папку и подобные.
Мне кажется, люди рассаживаются разреженно от незнакомых и в процессе заполнения зала — прибывающие протискиваются на оставшиеся места, тем самым мешая уже сидящим. Поэтому можно просто попросить людей сесть плотнее друг к другу и в том числе, занять первые ряды, сослаться при этом на то, что ждем опаздывающих — так они не помешают уже сидящим, просто займут задние ряды.
Можно сослаться на просьбу организаторов фото- и видеосъемки нашего выступления — нужен приятный :) и занятый первый ряд. Думаю, общие правила должны позитивно сказаться при просьбе рассадки.
К тому же, слышал, что плотная рассадка аудитории более выгодна для выступающего. Если так, то почему именно, Димитрий?
В 10-м пункте вы выделили необходимость улучшить дикцию. А на сколько важны уверенность или даже некий напор при публичных выступлениях (даже внутри своего небольшого отдела)? Как прокачиваться в этих направлениях?
Александр, спасибо, что поделились реальным опытом!
Особенно понравилось описание инструментария при планировании: просто о майках и покере на примерах из жизни :-)
Вы упомянули, что:
Декомпозиция — это трудоёмкий процесс. Именно он определяет этапы работы над новой фичей. Он требует знания архитектуры дорабатываемой системы и понимания протекающих процессов.
Речь о совокупности описанных и доступных для команды регламентов и процедур или же это, например, знание опытного сотрудника? А как тогда ваша команда избегает бас-фактора в таких ценных знаниях?
Точно. Поэтому я описал выше, что нужно соблюдение сроков сделать основным принципом команды. Корректировать по факту, внутри проекта будет менее эффективно.
Игорь, согласен, описание в правилах, как действовать, в случае сбоя принесёт пользу команде. Да и в сущности управления рисками нужно, чтобы минимизировать ущерб при сбоях. Но сначала нужно наладить и описать принципы работы без сбоев, систему. А как побудить сотрудников её соблюдать? Мне показалось, что свой взгляд на это и описал автор.
Сроки всегда и везде меняются и будут меняться — это истина)
Когда речь о принципах работы и их описании, я склонен внедрять и применять только безусловно универсальные решения. Как лекарства в медицине вводят только после высочайшего процента воздействия на определенные участки организма. Иначе плацебо было бы и то эффективнее.
Так и в принципах соблюдения дедлайнов в работе. Простой пример: в мастерской печати на тканях нужно изготовить плакат к 8 мая, потому что 9 мая заказчик понесёт плакат в руках на демонстрации в центре города. Принципиально похожих примеров и в масштабных проектах — масса, а значит возможность сдвига сроков не могу считать истиной.
Другое дело, что если, в крайнем случае, придётся резать по живому и чем то жертвовать, то функциональностью, а не дедлайном. Например, не нанимать шрифтовика, а сделать на плакате надпись готовым шрифтом или, к примеру, использовать более простой метод нанесения краски на ткань.
Собственно, идея приоритетов на дедлайне полностью перекликается с вашими идеями в статье.
Принципы менять нельзя. То «да», то «нет» при регламентировании — не выход. Согласны?
Станислав, в моём восприятии откликается основная цель вашей статьи — приоритет на дедлайне, особенно то, что вы выбрали основной стратегией помочь коллегам понять пользу соблюдения сроков! Особенно универсальными, а от этого полезными более широко, мне показались пункты об Объяснении и Эффективных инструментах. Объяснение, потому что точно зная пользу, которую вы доведёте до коллеги, он точнее поймёт и выполнит задачу. А правильно подобранный инструмент позволит избежать ограничений, навязанных атавизмами другого неподходящего инструмента.
Я бы хотел выделить, то, с чего нужно начать строить приоритет и важность, на мой взгляд, и очень жаль, что мысль спряталась в середине статьи:
«Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам».
Если вы понимаете особую ценность дедлайна, нужно вписать это в конституцию своей компании или команды!
Тогда все остальные пункты станут второстепенными и не придётся влиять на восприятие коллег уже в начатом проекте, иначе каждое изменение будет стоит титанических усилий. И наоборот, принципы, с которыми согласились при старте работы, даже раньше старта отдельных проектом, ставшие базовыми принципами — будут легко применяться в проектах.
Я не полностью понял основные пункты советов: Ставьте только реальные дедлайны и Позволяйте команде ставить сроки. Неуниверсально, так как часто дедлайн ставит заказчик, которому нужно успеть к старту второй стадии его проекта. Я понимаю, что опыт аналогичных проектов нужно учесть на стадии составления плана работ, где как раз появятся понимание дедлайна.
Но в итоге, из трёх основных измерений — срок, бюджет, функциональность — придётся чем-то пожертвовать, ведь за даже в быту за город на отдых не выехать без изменения в сроке поездки, бюджете или количестве посмотренных достопримечательностей :-), что говорить более сложных проектах в компаниях, где каждый раз получается, не так:
а так: картинки я взял со страницы принципов работы Бюро Горбунова
Мне пункты понравились универсальностью, ведь их можно применить в любой профессии, лишь с небольшими адаптационными ремарками: в любой деятельности, человек отвечает за результат своей работы и, по сути, является проджект-менеджером, хозяином своего продукта.
Хотел бы отметить, что при чтении, замешкался на 18-м пункте. Возможно, на языке оригинала «Имеет твёрдую точку зрения, но слабо её придерживается» звучит кристально понятно, но я перечитывал и сопоставлял заголовок пункта со смыслом абзаца — несколько раз. В итоге, для себя в голове уложил смысл пункта под заголовок «Проверяет свою теорию на прочность». Скорее всего, это лишь моё индивидуальное восприятие. Что скажете?
Мне понравилось, как просто вы описали основные процессы ITIL, сразу видно, что именно делает и легко примерить пользу даже для небольших компаний.
Неагрессивно рассказываете о своей системе. Хотел бы прочесть примеры внедрения хелпдеска прямо на конкретном малом предприятии из вашей практики, ведь нет ничего ценнее реального опыта.
Точно подмечено, Дмитрий!
Все самое важное для нас — дается легко и без напрягов. На то оно и родное дело, свое.
Чтобы не фрагментировать восприятие личного результата, я стал использовать принцип «Одно большое дело в год». Этот принцип пять лет назад сформулировал Стас Кулеш:
Суть его заключалась в том, что на каждый год планируется одно большое дело, а остальные помечаются тэгом «было бы неплохо». Опыт показывает, что невзирая на болтания, апатии, страдания, трудности и прочие составляющие человеческого бытия, на одно дело целеустремлённости хватает.
Дмитрий, спасибо за совет!
Можно попросить пару тезисов из книги? Какую главную мысль почерпнули для себя после прочтения? О какой сущности речь именно у МакКеона?
Идея переключения внимания — кайфовая. Но такое переключение сильно влияет на ткань наших дел. К тому же, может оказаться, что как раз принесет отрицательный эффект, так как придется именно заставлять себя это делать. Это опять отток сил, поэтому и исчерпывается уже через десять дней, по вашему описанию.
Если же именно это и приносит энергию, то такой режим, может с некоторыми адаптациями, лучше встроить на постоянной основе. Тогда он будет питать силами постоянно.
Работники интеллектуального труда вместе с тем имеют опыт применения системного подхода в решении задач: понять задачу, составить план решения и сделать. Именно этими инструментами мы с вами и обмениваемся на Хабре, верно?
А спады настроения полезно анализировать и классифицировать, что бы к этому кризису не привело частыми повторениями этих спадов. Как в ИТ-практиках: повторяющийся инцидент — это уже проблема и методологии решения уже с применением других процессов.
Точно. Пока проводил такую инвентаризацию дел, именно это помогло не загрузиться лишним еще больше. Энергия всегда конечна и нельзя ее просто исчерпать. Нужно наполнятся и там, что будет питать.
Разделяю с вами необходимость хобби! У меня всегда было хобби, но своей ошибкой считаю то, что оно тоже связано с Ай-ти. Получается, в моем случае, хобби просто было продолжением работы.
Сейчас я срастил бывшее хобби и и работу, так как не хочу отказываться от него и завел новые любимые занятия, совсем не связанных с техникой. Чувствую, что это питает мои силы насыщеннее.
Чтобы понять что нравится, а что нет, рекомендую подробнее изучить процесс, на который я тогда опирался.
А секрет его прохождения — сделать это легко, не напрягаясь. Уж слишком много у нас лишнего, которое и так давит, правда же?
Понимаю, что этом мелочи этапа, но тем не менее.
Например, если пропущен пункт sftp, не сконфигурирован sftp-порт — не запустится резервирование журналов; если не внесены параметры в ветку реестра «x», то профиль оборудования не отразится в мониторинге.
Таким образом, каждый пункт листа должен быть отмечен, иначе проверка не пройдена, не завершена.
В противном случае, это лишь пункты списка и требуют других инструментов в работе, например, Ту-ду лист с возможностью переноса в другую папку и подобные.
Как полагаете, коллеги?
Можно сослаться на просьбу организаторов фото- и видеосъемки нашего выступления — нужен приятный :) и занятый первый ряд. Думаю, общие правила должны позитивно сказаться при просьбе рассадки.
К тому же, слышал, что плотная рассадка аудитории более выгодна для выступающего. Если так, то почему именно, Димитрий?
Рад видеть вас на Хабре :-)
В 10-м пункте вы выделили необходимость улучшить дикцию. А на сколько важны уверенность или даже некий напор при публичных выступлениях (даже внутри своего небольшого отдела)? Как прокачиваться в этих направлениях?
Особенно понравилось описание инструментария при планировании: просто о майках и покере на примерах из жизни :-)
Вы упомянули, что:
Речь о совокупности описанных и доступных для команды регламентов и процедур или же это, например, знание опытного сотрудника? А как тогда ваша команда избегает бас-фактора в таких ценных знаниях?
Когда речь о принципах работы и их описании, я склонен внедрять и применять только безусловно универсальные решения. Как лекарства в медицине вводят только после высочайшего процента воздействия на определенные участки организма. Иначе плацебо было бы и то эффективнее.
Так и в принципах соблюдения дедлайнов в работе. Простой пример: в мастерской печати на тканях нужно изготовить плакат к 8 мая, потому что 9 мая заказчик понесёт плакат в руках на демонстрации в центре города. Принципиально похожих примеров и в масштабных проектах — масса, а значит возможность сдвига сроков не могу считать истиной.
Другое дело, что если, в крайнем случае, придётся резать по живому и чем то жертвовать, то функциональностью, а не дедлайном. Например, не нанимать шрифтовика, а сделать на плакате надпись готовым шрифтом или, к примеру, использовать более простой метод нанесения краски на ткань.
Собственно, идея приоритетов на дедлайне полностью перекликается с вашими идеями в статье.
Принципы менять нельзя. То «да», то «нет» при регламентировании — не выход. Согласны?
Я бы хотел выделить, то, с чего нужно начать строить приоритет и важность, на мой взгляд, и очень жаль, что мысль спряталась в середине статьи:
«Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам».
Если вы понимаете особую ценность дедлайна, нужно вписать это в конституцию своей компании или команды!
Тогда все остальные пункты станут второстепенными и не придётся влиять на восприятие коллег уже в начатом проекте, иначе каждое изменение будет стоит титанических усилий. И наоборот, принципы, с которыми согласились при старте работы, даже раньше старта отдельных проектом, ставшие базовыми принципами — будут легко применяться в проектах.
Я не полностью понял основные пункты советов: Ставьте только реальные дедлайны и Позволяйте команде ставить сроки. Неуниверсально, так как часто дедлайн ставит заказчик, которому нужно успеть к старту второй стадии его проекта. Я понимаю, что опыт аналогичных проектов нужно учесть на стадии составления плана работ, где как раз появятся понимание дедлайна.
Но в итоге, из трёх основных измерений — срок, бюджет, функциональность — придётся чем-то пожертвовать, ведь за даже в быту за город на отдых не выехать без изменения в сроке поездки, бюджете или количестве посмотренных достопримечательностей :-), что говорить более сложных проектах в компаниях, где каждый раз получается, не так:
а так:
картинки я взял со страницы принципов работы Бюро Горбунова
Мне пункты понравились универсальностью, ведь их можно применить в любой профессии, лишь с небольшими адаптационными ремарками: в любой деятельности, человек отвечает за результат своей работы и, по сути, является проджект-менеджером, хозяином своего продукта.
Хотел бы отметить, что при чтении, замешкался на 18-м пункте. Возможно, на языке оригинала «Имеет твёрдую точку зрения, но слабо её придерживается» звучит кристально понятно, но я перечитывал и сопоставлял заголовок пункта со смыслом абзаца — несколько раз. В итоге, для себя в голове уложил смысл пункта под заголовок «Проверяет свою теорию на прочность». Скорее всего, это лишь моё индивидуальное восприятие. Что скажете?
Неагрессивно рассказываете о своей системе. Хотел бы прочесть примеры внедрения хелпдеска прямо на конкретном малом предприятии из вашей практики, ведь нет ничего ценнее реального опыта.
Все самое важное для нас — дается легко и без напрягов. На то оно и родное дело, свое.
Чтобы не фрагментировать восприятие личного результата, я стал использовать принцип «Одно большое дело в год». Этот принцип пять лет назад сформулировал Стас Кулеш:
Можно попросить пару тезисов из книги? Какую главную мысль почерпнули для себя после прочтения? О какой сущности речь именно у МакКеона?
Если же именно это и приносит энергию, то такой режим, может с некоторыми адаптациями, лучше встроить на постоянной основе. Тогда он будет питать силами постоянно.
А спады настроения полезно анализировать и классифицировать, что бы к этому кризису не привело частыми повторениями этих спадов. Как в ИТ-практиках: повторяющийся инцидент — это уже проблема и методологии решения уже с применением других процессов.
Сейчас я срастил бывшее хобби и и работу, так как не хочу отказываться от него и завел новые любимые занятия, совсем не связанных с техникой. Чувствую, что это питает мои силы насыщеннее.
Чтобы понять что нравится, а что нет, рекомендую подробнее изучить процесс, на который я тогда опирался.
А секрет его прохождения — сделать это легко, не напрягаясь. Уж слишком много у нас лишнего, которое и так давит, правда же?