Продолжая тему замечательных решений, я недавно обнаружила чудеснейший столик как раз для таких совещаний, который создал дизайнер John Hannah. Собравшись вокруг такого стола, вы можете рисовать на нем все что угодно: записывать идеи, строить mind-map и т.п. Это такая себе доска, встроенная в стол

Я не утверждаю, что такой стол  лучше, чем доска на стене, но само решение более чем интересно

В чем же прелесть этих совещаний стоя и вокруг такого стола в частности?

Когда стоят, через очень короткое время у них возникает желание присесть, а пока такая встреча не закончиться – сесть не получится, поэтому решения принимаются быстрее, никто не растекается мыслью по древу, нет места длинным беседам не о чем, все проходит коротко и по существу. А если проходит коротко и по существу, то такие встречи проводить можно часто, что очень положительно влияет как на работу всей команды в целом, так и на оперативное выявление проблем в частности, чем длинные и скучные собрания, которые зачастую делают «для галочки».

Я думаю, ни у кого не возникает сомнений, что собрания проводить нужно. Другой вопрос в том, что эти собрания должны приносить пользу и, я бы даже сказала, какое-то удовольствие

А как у вас проходят совещания? Полезно? Весело? Скучно? Интересно?

Статьи по теме

• Совещания без разочарований
• Игры, в которые люди играют на совещаниях – часть вторая
• Игры, в которые люди играют на совещаниях – часть первая
• Об инструментах или что нам помогает делать хороший Scrum
• Наглядно об основах Scrum

© Мария Евграшина для The Improved Methods, 2010. | Permalink

Одни говорят – дайте мне приличную зарплату и ваша мотивация мне совсем не нужна, я хочу получать большую зарплату и сам решать ходить мне пешком по офису или ездить на самокате. Другие говорят, что все зависит от руководителя, что если он умеет всех «мотивировать», и даже если проект скучный, и зарплата средне рыночная, но руководитель с харизмой, то вокруг него соберется интересная команда. Третьи скажут, что главное проект – если я делаю что-то, что никто до меня не делал, если проект безумно интересный, то не так и важно, что руководитель не самый лучший, и зарплата не самая высокая. Правда у каждого своя

Истина как всегда где-то посередине. Конечно, самый идеальный вариант: это высокая зарплата, безумно интересный проект и харизматичный руководитель, у которого всегда есть чему поучиться Если у вас все так, то этот пост не для вас.

Если же рассматривать каждый компонент «удовлетворенности», то хочется очень сказать, что зарплата никак не относится к мотивационному фактору. Мотивация начинается после того, как есть нормальная зарплата. Если зарплаты нет, то ни о какой мотивации не может идти речи. Я уже писала о гигиенических факторах Герцберга. Не буду их еще раз пересказывать, просто хочу отметить, что прежде чем придумывать мотивацию, задумайтесь, а все ли у вас в порядке с «гигиеной»?

Еще хочется поаппелировать к тем, кто считает, что им кроме зарплаты ничего не нужно. Мол, дайте мне хорошую зарплату и меня все устроит. Причем это проблема двух сторон, руководители (скорее даже владельцы бизнеса) частенько считают, что если я плачу хорошую зарплату, то можно обо всем остальном не заботиться. Если посмотреть на эту ситуацию со стороны сотрудника, то да, люди готовы работать в офисе на отшибе, без всяких социальных благ, со скучным проектом, но… как долго? Хм… не поверите, но бывает, что очень долго. Почему? Причин может быть много: лень, страх что-то изменить, самообман. Это как в том анекдоте «Мышки, кололись, плакали, но продолжали жрать кактусы». Кто-то скажет, что это преданность компании, проекту, а я думаю, навряд ли.

Да, тяжело уходить с высокой зарплаты на меньшую, но более перспективную. Только очень рисковый и уверенный в себе человек может себе это позволить. Большинство остается барахтаться в болоте, ища себе оправдания. А руководитель себя тешит самолюбием, что раз у него люди так давно работают, то он просто интересный человек и харизматичный лидер

На самом деле, продолжая изо дня в день делать одно и то же, не пытаясь что-то изменить, люди подвергаются такому психическому состоянию, как монотония.

Что это такое?

Монотония (от греч. monos – один, единый и tonos – напряжение, ударение) — функциональное состояние человека, возникающее при однообразной работе. Характеризуется снижением тонуса и восприимчивости, ослаблением сознательного контроля, ухудшением внимания и памяти, стереотипизацией действий, появлением ощущений скуки и потери интереса к работе. Продуктивность деятельности лишь на некоторое время восстанавливается за счет включения особых волевых усилий. В ответ на монотонные условия работы могут развиваться и явления психического пресыщения. В отличие от усталости является так называемым «переходным» состоянием, которое может быстро исчезнуть при смене работы или условий труда.

Нужно ли вам такое состояние? А нужен ли работодателю такой сотрудник? Ответ очевиден

Перечитала все, что написала выше – получился какой-то грустный монолог, и нет ответа на вопрос «А что же делать?». Сложно подобрать лекарство от всех недугов, серебряной пули нет. Вы можете пойти на тренинги личностного роста, обратиться к карьерному консультанту, поработать с life-коучем, но прежде чем все это сделать, попробуйте поработать сами над собой. И тут очень кстати придутся цели в жизни. А можете начать просто с какой-то хорошей книги, которая поможет вам взглянуть на свою жизнь иначе. Это я все к тому, что как бы мы кого-то не пытались мотивировать, очень важна самомотивация человека. Только мы сами в состоянии создать себе самую правильную мотивацию.

Статьи по теме

• Культ времени
• Время оглянуться назад и поставить цели на будущий год
• Несколько мыслей на тему мотивации
• Как избежать стресса
• Мечты и цели

© Мария Евграшина для The Improved Methods, 2010. | Permalink

Сразу оговорюсь, я не буду рассказывать, где и как найти кандидата – об этом лучше расскажут опытные рекрутеры. Я рассказываю только о том, что должны  делать менеджеры проектов (командные лидеры и прочие), кто пришел на “техническое собеседование” кандидата.Свои первые собеседования я начал году в 2000-м. Почти сразу стало ясно, что даже если человек вас впечатлил знаниями во время беседы, то не факт, что он окажется хорошим членом команды и не уйдет через 3-6 месяцев. Со временем, у меня выработался подход, который я теперь всегда применяю, и который зарекомендовал себя с лучшей стороны.

Отвечая на возможные вопросы – да, я искал книги и статьи на эту тему, и, к сожалению, многое из того, что я нашел, было написано людьми далекими от рекрутинга в целом и собеседований технических специалистов в частности Единственная толковая статья, которая мне попалась – это была статья Джоэля Спольски The Guerilla Guide to Interview, которая существует уже в третьей (!) редакции. Поэтому дальше я буду цитировать его по мере своего рассказа, даже если я не на 100% с ним согласен

Итак, у вас назначено собеседование с кандидатом. Еще до того как вы туда пойдете, следует уяснить и запомнить вашу цель собеседования. Как сказал Джоэль:

You’re looking for people who are

1. Smart, and
2. Get things done.

That’s it. That’s all you’re looking for.

Мы ищем человека “толкового и умеющего доводить дело до конца“. По большому счету за 30 (ну 60 максимум) минут можно выяснить не так уж много. И многие “человеческие” качества вы узнаете потом. Сейчас вам главное быстро определить подходит вам кандидат или нет. Причем очень важно, чтобы он(она) одновременно обладал обоими качествами.

Если только “умный”, но не умеет доводить дело до конца, то скорее все закончится идеями типа “давайте все переделаем” или умными рассказами о новых библиотеках (как раз в тот момент, когда вся команда собирает финальную сборку перед выпуском).  Был у меня молодой сотрудник, который подстрекаемый юношеским максимализмом и своими свежеприобретенными знаниями, “переработал” небольшое системное приложение, состоящее из 2-х классов в монстра из более чем 30 классов. После чего все, кто дорабатывали это приложение, ругались даже спустя годы как он ушел из команды.

Если человек бестолковый, но доводит дело до конца, то это может оказаться замедленной бомбой для команды. Он будет делать ошибки и даже не осознавать их. Другой, толковый, сотрудник будет их постоянно исправлять и в итоге устанет и просто уйдет из команды.

1. Итак, надеюсь, вы заучили мантру и встречаете кандидата. Прежде чем переходить к делу, потратьте одну-две минуты, чтобы немного “расслабить” человека. Спросите, как он добрался, легко ли вас нашел. Предложите чай. Для любого кандидата собеседование – это стресс, и потратив эти две минуты, вы  сможете получить больше информации и лучше провести интервью. Не забудьте представиться, назвать свою роль, и рассказать о цели собеседования: о позиции, на которую мы собеседуемся и о том, как пройдет интервью (т.е. структуру, которую я и описываю).
2. Дальше идет очередь рассказа о прошлых проектах. Даже если вы читали резюме, то все равно попросите кандидата рассказать о его прошлых проектах. Если человек “застрял”, то просто читая в CV название или описание прошлого проекта, вы можете сказать “расскажите, пожалуйста, об этом чуть подробнее”. Слушая этот рассказ, вы должны обратить для себя внимание сразу на несколько моментов:
   • Понятность изложения. Даже если человек рассказывает о сложном научном проекте или бизнес области, мало известной лично вам, то он может делать это понятным языком или наоборот, используя кучу сленговых выражений (тем самым показывая свой снобизм, свое превосходство). Если кандидат может объясняться доступным языком, то это означает, что он способен объяснить сложные вещи, адаптируясь к уровню собеседника. Например, он сможет простыми словами объяснить заказчику выгоды от использования новых библиотек, изменений в старом коде, автоматизации тестирования (нужное подчеркнуть) и т.п. Также с другими членами команды, он наверняка быстро найдет общий язык.
     Однажды мне рассказали о достаточно сложном проекте для медицины так, что я до сих пор считаю, что я запросто мог бы его использовать
   • Также в рассказе должна присутствовать страсть. Как говорить Джоэль: неважно, позитивная или негативная (как, например, рассказ о недальновидном или просто глупом начальнике), важно чтобы она была. Даже если вы не видите “огонька” в рассказе о прошлом месте работы, то можно спросить о самом лучшем и самом плохом проекте, где он работал. Важно помнить, что если человека ничего не интересует, то вы никак не сможете “мотивировать” такого человека. Он будет просто “отсиживать” свои часы и делать не больше среднего работника. С командной работой тоже могут в будущем возникнуть нюансы.
   • Ну и слушая рассказ о прошлой работе, обращайте внимание на примеры коллективной работы, а особенно на те случаи, когда кандидат проявлял инициативу (или даже лидерские качества). Важно, что если даже в проекте были проблемы, а кандидат выступил с предложением или просто собрал команду, чтобы вместе придумать решение – это хорошие проявления лидерства (пусть даже вы собеседуете рядового разработчика). Я могу, конечно, сослаться на концепцию “проактивности”  у Стивена Кови или других авторов, хотя объяснение может быть и проще. Любой пример того, что человек добился чего-то, преодолевая препятствия – уже хороший знак того, что он умеет доводить дело до конца.
3. После того, как вы достаточно узнали об опыте кандидата, наступает очередь простых технических вопросов. Обычно я прошу написать какую-то простую функцию, на языке, основном для этой вакансии. Что-то типа “массив целых чисел заполнить случайным образом и выкинуть от туда все двойки”. Это должно быть что-то достаточно простое и не требующее знания сложных алгоритмов. Да,  компилятора нет под рукой, не страшно, мы не будем обращать внимание на мелкие ошибки  Суть этого шага – узнать умеет ли кандидат писать код, и важно как быстро он справится с таким простым заданием. Кому-то нужно сначала набросать пример кода, а кто-то сразу начнет рассказывать, как он видит решение и записывать код по ходу рассказа. Как видите, вопрос был достаточно размытый и по ходу того, как человек крутит его в голове, у него должны появиться разумные и иногда очень интересные уточняющие вопросы (типа какой длины массив и т.п.) – все это признаки хорошего специалиста. Плохой специалист может надолго уйти в себя и в лучшем случае признаться, что не понял, а в худшем вообще ничего внятного не написать.
   Однажды, у меня был кандидат, который долго рассказывал о прелестях объектно-ориентированного проектирования с помощью приложения Rational Rose, а на мой вопрос “в каком IDE вы работаете” посмотрел на меня удивленно и выдал: “я же говорю – мы все делаем в “Розе”.
   Если вы собеседуете не разработчика, а скажем тестера (или  QA специалиста), то можно, например, попросить придумать возможные тесты для формы создания записи о сотруднике, где есть 4-5 полей разного типа. Так или иначе, вы можете выделить простые технические вопросы, для своей области.
4. К  сложным техническим вопросам можно переходить, когда кандидат успешно справился с простым заданием. Тут уже вам решать насколько глубоко прощупывать его знания. Если рекрутеры давали какой-то технический тест, то можно использовать его как “повод для разговора” и попросить рассказать о тех вопросах, где он допустил ошибку. Главное не задавать “энциклопедических” вопросов, которые требуют наличия справочника под рукой или наличия практического опыта.
5. После того, как “отстрелялись” с сугубо технической частью, нужно потратить еще немного времени и узнать побольше о кандидате вне его профессиональной деятельности. Я много работаю с иностранными заказчиками, поэтому эта часть носит характер «About myself» кандидата и заодно проверяется уровень английского у кандидата. Кроме базовых вопросов о семье и хобби, остальные предлагаю придумать вам самим и рассказать  мне и читателям. Джоэль Спольски много пишет о “политкорректных” вопросах, хотя для нас это не так актуально
6. Ну и предпоследний, немаловажный, этап – это презентация самого проекта, которую проводите вы сами. Даже если кандидат вам не понравился в самом начале, вы можете пропустить сложные вопросы, но оставьте эту часть. У кандидата есть друзья и коллеги, поэтому если вы интересно расскажете о проекте, возможно, кто-то другой захочет к вам прийти. А уж если кандидат вам подходит, и самому понравился, то во многом от вашего красочного рассказа зависит, будет ли он у вас работать.
7. Обязательно, в конце оставьте время и место для ответов на вопросы кандидата. Как бы хорошо рекрутеры не рассказывали про компанию в целом, все равно останутся вопросы. Потрудитесь на них всесторонне ответить или хотя бы сообщить, что вы не можете этого сделать и посоветовать, у кого можно получить эту информацию.

Ну и после того, как вы распрощались с кандидатом, у вас есть всего одно действие – написать рекрутерам БЕРЕМ или НЕ БЕРЕМ. Не нужно вилять и придумывать оправдания, если кандидат вам хоть чуточку не понравился. Возможно, вы предвзяты, возможно, нет – лучше не рисковать. Проще сказать нет, хорошему кандидату, который, наверняка, не останется без работы, чем взять заведомо плохого члена команды,  которому, в итоге, через шесть месяцев будете искать замену. Проще поискать хорошего сейчас, чем тратить время потом.

Надеюсь, что такое длинное и подробное объяснение поможет вам найти хороших сотрудников. Буду признателен, если вы поделитесь своим опытом и своими идеями, как улучшить процесс подбора сотрудников.

Статьи по теме

• Мастер-класс о внедрении Scrum в Днепропетровске
• Интервью с Майком Коном
• Определились спикеры дискуссионного клуба Agile-практиков
• Почему руководителей не любят?
• Эффект хомячков

© Тимофей Евграшин для The Improved Methods, 2010. | Permalink

Мастер-класс «Преодоление препятствий внедрения Scrum в играх и обсуждениях» пройдет в Днепропетровске  20 марта, в субботу.

Мы обсудим и обыграем основные проблемы и препятствия, которые встречаются на пути внедрения Scrum. Мы надеемся, что вы сможете посмотреть на многие препятствия под другим углом и избежать их в будущем. Более того, наше общение не закончится после мастер-класса. Все получат «домашнее задание», и его разбор через некоторое время после мастер-класса.

Также хочу напомнить, как мы анонсировали ранее,  13 марта такой же мастер-класс пройдет в Харькове.

Подробная информация о мастер-классе.

Статьи по теме

• Интервью с Майком Коном
• Эффект хомячков
• Ближайшие мероприятия
• Пора отпусков и Scrum
• ABC Украинского Agile сообщества

© Тимофей Евграшин для The Improved Methods, 2010. | Permalink

Не буду петь дифирамбы или ругать,  а просто поделюсь своими личными ощущениями

Я уже не раз писала и говорила, что у каждого инструмент свой, и то что подходит одному, может абсолютно не подойти другому.

В общем, попользовавшись полтора месяца ежедневником, я вернулась к своему планингу. Планингами я пользуюсь уже года четыре, и очень привыкла, мне удобно – я вижу всю неделю, вижу основные задачи на неделю и задачи-встречи на каждый день. Ежедневник сложно держать все время открытым, и даже если и держать – все равно видишь только 2 дня, в отличие от планинга. Единственное, что я утащила из ежедневника Архангельского, – это стратегическая картонка. Мощная штука! На стратегической картонке написаны цели, и каждый раз обращаясь к ежедневнику (а сейчас – планингу), я смотрю на эти цели, и хочешь-не хочешь возникает мысль: “А сделала ли я что-то на этой неделе, чтобы их достичь?”. Прекрасный инструмент самомотивации

На самом деле, если вы привыкли пользоваться ежедневником, то инструмент от Архангельского подойдет вам как нельзя лучше, очень удобно, что есть «слоники» и «лягушки», закладки для контекстных задач, деление страницы на жесткие встречи и гибкие задачи. Что однозначно неудобно – это отсутствие дат. Хоть это и подается как «фишка», что, мол, вы можете начать вести ежедневник в любой день года, это неудобно. Представьте себе, что сегодня 22 февраля, а я хочу поучаствовать в мероприятии, которое будет через месяц? Ну, не буду я проставлять даты на целый месяц вперед : -( Найти выход конечно можно, но все равно уже не то… Из минусов еще отмечу очень мягкую обложку, при желании можно конечно купить и одеть кожаную обложку для книг , но опять же… И еще скажу о резиночке – это такая себе претензия на молескин, у меня она оторвалась после второго одевания на ежедневник В общем, все минусы не критичны, в целом инструмент получился хороший, и его есть куда развивать.

Что хочется еще добавить. Если у вас есть инструмент, который прекрасно работает, и вы не чувствуете надобности что-либо менять, то и не надо, потому что «супер-пупер» инструмент не всегда то, что нужно именно вам. Я бы и не отказалась от своего планинга, но вести 2 ежедневника – бред, а попробовать и поделиться впечатлениями уж больно хотелось

Статьи по теме

• Культ времени
• Где к вам приходят самые гениальные идеи?
• Ежедневник как один из инструментов
• Инструменты работы в команде: "Обратная связь"
• Мифы об управлении временем

© Мария Евграшина для The Improved Methods, 2010. | Permalink

Почему я решил пообщаться именно с Майком Коном? Просто познакомившись с ним пару лет назад, я был впечатлен с какой ясностью и простотой он объясняет сложные концепции.  Майк Кон является одновременно основателем Agile и Scrum Альянсов – организаций взявших на себя почетную миссию развития, поддержки и популяризации Agile и Scrum во всем мире.  За свой более чем двадцатилетний опыт Майк был техническим руководителем компаний разных размеров – от стартапов до крупных компаний, входящих в список Fortune 40. И, конечно, многие из нас знают его как автора таких книг как Agile Estimating and Planning, User Stories Applied for Agile Software Development, Succeeding with Agile.

Майк, как вы относитесь к ScrumAlliance и что думаете о его дальнейшей роли? Особенно в связи со всеми изменениями, которые имели место за последний год.

Я был одним из основателей Scrum-Альянса вместе с Эстер Дерби и Кеном Швабером. Мы все пришли к тому, что пришла пора уйти из совета директоров, чтобы организация могла развиваться и без своих основателей. Эстер ушла первой, и я последовал за ней около 18 месяцев назад. Кен оставался в совете директоров до лета прошлого года. Затем меня попросили вернуться в совет, чтобы обеспечить Альянсу немножко преемственности оригинального виденья, что я и буду делать в течение года или около того. Затем я хочу снова выйти из организации, и позволить ей развиваться без своих основателей.

Что касается будущего Scrum-Альянса, я думаю, что все будет хорошо. Есть целый ряд новых программ, которые были недавно объявлены. Например, программа “Зарегистрированный Провайдер Обучения (Registered Education Provider)” поможет людям найти не сертифицированные курсы, которые могут повысить уровень знаний Scrum-мастеров и Владельцев Продукта. Была создана программа “Сертифицированный Scrum разработчик“, где Зарегистрированные Провайдеры Обучения могут преподавать классы, что позволит разработчикам показать свою преданность техническим навыкам, необходимым для того, чтобы хорошо делать Scrum. Scrum-Альянс также недавно объявил об изменениях в CSM-тесте, который стал обязательным для сертификации с октября 2009 года. Тест будет по-прежнему обязателен, но сам он был значительно улучшен. Вместо того чтобы дать просто оценку (“Вы дали 89% правильных ответов”), всем кто сдает тест, показываются правильные ответы на те вопросы, на которые они не смогли дать ответ, для того чтобы показать, в какой области у них не хватает знаний, и они могли бы продолжить свое обучение по этим темам. Это просто здорово, и приведет к тому, что Scrum-мастера будут обладать более глубокими знаниями. К сожалению, это означает, тест нельзя делать по принципу “сдал”/”не сдал”, потому что все вопросы не могут контролироваться, т.е. в скором времени они будут известны широкому кругу людей, так как люди будут делиться комментариями по тем вопросам, на которые они не смогли ответить. Тем не менее, это небольшая цена за то, чтобы дать людям с помощью теста результативную обратную связь.

Как, по вашему мнению, достиг ли Scrum пика своей популярности, и должно ли на смену ему прийти что-то другое?

Я так совсем не думаю. Много новых компаний проявляют к нему большой интерес в этом году. Думаю, что Scrum не будет чем-то заменен, а скорее просто постепенно исчезнет. Мне хочется, чтобы все agile-бренды в конечном счете исчезли, и осталось просто то, как мы разрабатываем программное обеспечение. Так же как объектно-ориентированная разработка происходит по умолчанию, так же мне хочется, чтобы agile-разработка была просто тем, что мы делаем.

Считаете ли вы Scrum методологией/фреймворком или же чем-то большим, вроде как философией или даже религией?

Все то, что может значительно улучшить чью-то жизнь или то, что может все изменить, рискует быть поставленным на религиозный пьедестал. И я вижу, что некоторые делают это со Scrum. Это не обязательно плохо, если это только личное ощущение, и оно не навязывается другим людям. Я же считаю Scrum методологией/фреймворком.

Недавно вы выпустили книгу “Succeeding with Agile”. Расскажите, пожалуйста, нашим читателям, о чем и для кого эта книга? Что вас подтолкнуло к написанию этой книги?

“Succeeding with Agile” – это результат четырехлетней деятельности. Книга о том, “как начать” и затем “как стать лучшим”. Ее предназначение стать помощником в Agile. Узнать об основах можно много где. Мне же хочется, чтобы прочитав другие книги и столкнувшись с некоторыми проблемами, в моей книге читатели смогли бы найти ответы на трудные вопросы и избежали их в будущем.

Есть ли у вас опыт работы с распределенными Agile командами? Если есть, то на какие характерные проблемы вы бы рекомендовали обратить внимание распределенным командам, которые только собираются начать практиковать Agile подход, например Scrum?

Я думаю, что невозможно не иметь опыт работы с распределенными командами. Они повсюду теперь. Если бы я должен был сказать только одну вещь о распределенных командах, то это было бы, что Agile работает в распределенных командах. Каждый раз, когда я делаю доклад на эту тему, люди спрашивают меня, работает ли Agile в таких случаях. Ну, конечно! Все хорошее в Agile – это то, что мы хотели бы иметь в распределенном проекте: частое общение, усиление акцента на тестирование, идея создания приложений потенциально готовых к концу каждой 2-4 недели, и т.д. Это все более чем важно для распределенной команды. Выгода в том, что Agile не позволяет команде “срезать углы”, как например, не общаться друг с другом в течение длительного периода.

Особенностью работы многих украинских команд, является то, что их менеджмент находятся за рубежом. Каким образом, по вашему мнению, они могут убедить руководство внедрить Agile/Scrum подходы?

Прежде всего я бы предложил каждый раз, когда это удобно, начать что-то делать, против чего руководство не может реально возражать: собираться вместе и планировать, что вы будете делать в течение короткого периода времени, в конце этого периода закончите запланированное, ежедневно общайтесь и т.д. Это всего лишь хорошая практика. Это итеративная и инкрементальная разработка и это начало того, чтобы быть Agile. Помимо этого, подумайте о том, против чего ваше руководство может возражать и посмотрите, может, вы сразу сможете прийти с какими-то метриками, чтобы предупредить их возражения заранее.

Бывали ли у вас случаи, когда вас просили помочь внедрить Scrum, а вы понимали, что Scrum им не поможет? Если да, то каковы были причины и что вы им советовали?

Иногда я все-таки начинаю работать с командой, хотя Agile не очень им подходит. Это неизбежно влияет на корпоративную культуру или людей, которые не были готовы к изменениям, которые привносит Agile.

Мой опыт показывает, что Scrum может помочь в не-IT областях, например в HR отделе. Есть ли у вас опыт внедрения Agile подходов вне IT и в каких областях, кроме IT, вы считаете, эти подходы будут работать лучше всего?

Agile и Scrum, конечно, могут использоваться вне IT. Мой опыт работы связан в основном с командами по разработке ПО, но я работал и с другими направлениями. В качестве примера далекого от разработки ПО приведу компанию Shamrock Foods, которая использует Scrum-подход для разработки и управления стратегией компании. Также сценарий ТВ-шоу “Герои” был написан спринтами. (Смотрите интервью со сценаристом Тимом Крингом)

Расскажите, пожалуйста, о своих планах на следующий год?

Ничего особо важного я планировал. Книга “Succeeding with Agile” вышла в ноябре 2009 года, и я планирую ее продвигать в этом году, поэтому я пока не буду начинать новые книги. У меня есть несколько идей, которые я уже запланировал реализовать, но пока еще рано о них говорить.

Что бы вы пожелали Украинскому Agile сообществу – всем тем, кто практикует Agile подходы в своей работе?

Я могу пожелать только, чтобы они могли и дальше популяризировать Agile-практики и принципы в своих организациях.

Статьи по теме

• Пора отпусков и Scrum
• ABC Украинского Agile сообщества
• О роли Agile менеджера
• "Черный лебедь" на проекте или как читать знаки, которые у нас есть
• Запись он-лайн дискуссии "Спроси Agile-практика"

© Тимофей Евграшин для The Improved Methods, 2010. | Permalink

Каждый раз, когда мы правильно распределили время, мы получаем моральное удовлетворение, а это служит профилактикой эмоционально тяжелых ситуаций.

Посмотрите в свой ежедневник отстраненным взглядом, так, как будто это не ваш, а чей-то чужой дневник. Посмотрите внимательно Очень-очень внимательно

То как вы распределили время на эту неделю – действительно то, чего вы хотите?

Одни из первых постов на этом блоге был посвящен тому, как поставить цели в жизни. На сегодняшний день этот пост по-прежнему один из самых популярных, его прочитали больше 2 тысяч человек, так что, думаю, тема актуальная. Поэтому хочу предложить еще одно упражнение, которое мне показалось интересным и достойным внимания.

Это упражнение показывает, как в повседневной деятельности проявляются наши приоритеты. Как говорится, если в ваш ежедневник не попали ваши приоритеты, то там обязательно окажутся чужие.

Упражнение основано на работе Стивена Кови и Дуга Ленника, оно помогает осознать, как именно вы используете время и что для вас важно. Упражнение простое, но требует высокого уровня самосознания и честности перед собой.

Возьмем 5 областей жизни: семья, здоровье, работа, общественная жизнь, обучение и рост.

Пошагово заполняем таблицу

* Не забывайте, что в неделе всего 168 часов

1. Определите, чего вы хотите в каждой из перечисленных областей. Запишите во второй колонке свое виденье для каждой области, цель, если хотите, так сказать «маячок», к которому хочется прийти. Формулировка должна быть краткой и очень простой. Например, быть здоровым и сильным, быть заботливым родителем, верным другом, получать удовольствие от работы и т.п.
2. Теперь в третьей колонке запишите, какие действия в течение недели приведут к достижению этой цели. Это должны быть конкретные дела. Например, если вы хотите стать более заботливым родителем, каждые выходные занимайтесь чем-то конкретным с каждым из своих детей. Если вы хотите быть здоровым, то вы можете запланировать каждый день делать зарядку или 3 раза в неделю посещать бассейн.
3. Следующий шаг. Теперь на каждое действие отведите определенное время в течение недели. Не забывайте, что все, что относится к сфере здоровья (например, достаточное количество часов на сон), способствует достижению всех поставленных целей.

Вы можете использовать это упражнения, чтобы оценить свое сегодняшнее положение, определив, на что вы больше всего тратите время.

После выполнения этого упражнения у вас может вырисоваться, например, такая картина:

Каждую неделю я провожу:

• 30 часов с детьми
• 20 часов с женой
• 5 часов с родителями
• 10 часов с друзьями
• 52 часа я сплю и занимаюсь спортом
• 5 часов у меня уходит на чтение книг и журналов
• 10 часов я посвящаю своему хобби

Значит, на работу остается 36 часов :0)

Понятно, что все условно, но главное понять, что мы очень загружены не потому, что у нас не хватает времени, а у нас не хватает времени, потому что мы очень себя загрузили.

Статьи по теме

• Время оглянуться назад и поставить цели на будущий год
• Мифы об управлении временем
• Восприятие времени
• Все ли у вас в порядке с «гигиеной»?
• Где к вам приходят самые гениальные идеи?

© Мария Евграшина для The Improved Methods, 2010. | Permalink

“Тюлень” консалтинг

Некоторые из нас консультанты “Тюлени”. “Тюлень” является верным и преданным одному единственному клиенту почти полный рабочий день. Консультант “Тюлень” делает глубокий вдох, ныряет, а затем остается под водой с клиентом в течение нескольких месяцев (хм.., возможно, Кит был бы лучшей метафорой). У “Тюленя” не так уж много времени на другие вещи, такие, как преподавание курсов или посещение конференций. Время от времени “Тюлень” появляется над поверхностью, чтобы сделать глубокий вдох и заодно узнать некоторые новые вещи, возможно, найти новых клиентов, а затем снова глубоко нырнуть.

“Тюленья” работа требует терпения и преданности делу. Вы должны проявлять особую осторожность, чтобы не погружаться слишком глубоко и слишком долго, и не забывайте хоть иногда всплывать, чтобы подышать и расширить свои горизонты. Вы также должны выбирать ваших клиентов осторожно, поскольку такое решение имеет большое влияние на вашу повседневную жизнь.

“Тюлени” обычно милые и веселые.

“Альбатрос” консалтинг

Некоторые из нас консультанты “Альбатросы”. Мы парим высоко в небе и преодолеваем большие расстояния. Время от времени мы погружаемся в воду и хватаем сочную рыбу, затем снова взмываем вверх в небо. У “Альбатроса” получается увидеть много разных мест – но он нигде не останавливается достаточно надолго, чтобы познакомиться с клиентом достаточно хорошо. “Альбатрос” гибкий и свободный. Никакой клиент не будет жаловаться, если “Альбатрос” решит провести неделю на конференции или написать книгу. С другой стороны, “Альбатрос” тратит значительную часть своего времени на координацию со своими клиентами и возится со своим графиком, пытаясь связать все друг с другом.

“Альбатрос” должен быть осторожен, чтобы не летать слишком высоко в облаках и не потерять связь с реальностью. В конце концов, там, в небе может быть одиноко и небезопасно, всегда в движении, не имея собственного уютного кабинета, который можно назвать домом. Выгоды большие, но свобода имеет свою цену.

“Альбатросы”, как правило, быстрые и грациозные.

“Утка” Консалтинг

Некоторые из нас консультанты “Утки” – компромисс между “Тюленем” и “Альбатросом”.

Также как и у “Тюленя”, у нас есть один конкретный клиент, на котором мы сосредоточены. Однако, в отличие от “Тюленя”, мы не проводим все свое время под водой с этим единственным клиентом. Как и “Альбатрос”, мы иногда расправляем наши крылья и посещаем других клиентов или преподаем курсы, или посещаем конференции. Но у “Утки” есть один особенный пруд, куда он любит возвращаться – клиент, которого он хорошо знает, и скорее всего, проводит с ним один или два дня в неделю. Достаточно долго, чтобы познакомиться с клиентом, но не достаточно долго, чтобы засидеться на поверхности воды.

“Утки”, как правило, приятные и веселые.

“Удильщиковый” консалтинг

Некоторые из нас были когда-то консультантами в стиле “Рыбы Удильщика”, до прихода в Crisp.

“Удильщики” в неведении, потерянные, бродят бесцельно, и у них нет ничего, кроме небольшого искусственного света, который направляет их. Иногда им везет и удается привлечь мелких рыб. В отличие от “Альбатросов”, “Удильщик” не видит горизонта, и не выбирает, куда идти – он просто плавает вокруг и ест все, что попадется. “Удильщик” никогда не выходит на поверхность, чтобы увидеть общую картину или узнать что-то новое – на самом деле, он даже не знает, в каком направлении находится поверхность.

“Удильщики” обычно уродливы и страшны.

А к какому типу консультантов относитесь Вы? Например, о себе Хенрик пишет:

Большинство из нас меняет роли время от времени. Я был “Тюленем”. Теперь я “Альбатрос”, и в надежде стать больше “Уткой” в течение следующего полугода или около того. <самореклама> Дайте мне знать, если вам нужен консультант “Утка”, в течение одного дня в неделю или около того: о) </самореклама>

Думаю, только асоциальные “Удильщики” не получают удовольствия от общения с коллегами и обмена опытом. Лично для меня недавняя конференция AgileBaseCamp продолжилась общением с моими коллегами, которые консультируют или на практике помогают командам становиться более гибкими. Очень надеюсь, что в ближайшем будущем сообщество русскоговорящих Agile консультантов будет развиваться и появятся люди, относящиеся к разным типам, согласно классификации Хенрика Книберга

Оригинал статьи.

P.S. (Как сказал Хенрик: “фотографии выше, собственность того, у кого я их украл”)

Статьи по теме

• Консультанты, тренеры, коучи и другие милые люди
• Интервью с Майком Коном
• Определились спикеры дискуссионного клуба Agile-практиков
• Ближайшие мероприятия
• Зачем мы играем в покер на работе

© Тимофей Евграшин для The Improved Methods, 2010. | Permalink

Мы приглашаем всех читателей нашего блога принять участие в обсуждении.

В этот раз  к нам любезно согласились присоединится Алексей Кривицкий, Николай Алименков и Евгений Компаниец, за что им отдельное спасибо!

Итак, о чем поговорим:

• типичные проблемы Scrum-команд и пути их решения
• основные ошибки в работе с распределенными командами
• с чего начать внедрение Scrum в команде?
• как происходит планирование проектов?
• как убедить заказчика изменить процессы?
• возможна ли самоорганизация в неоднородных по профессиональному уровню командах
• разберем кейс об организации работы с материальными артефактами (user story cards и доской в частности)

и другое…

Тем немного, но уже и на их обсуждение уйдет немало времени. Спасибо всем, кто уже задал вопросы.

Для всех остальных еще есть возможность задать вопросы, дискуссия обещает быть интересной Так что спрашивайте,  а если нет вопросов, просто присоединяйтесь в качестве слушателя

Немного о спикерах:

Тимофей Евграшин – тренер по внедрению гибких методологий управления проектами Agile/Scrum, практикующий Scrum-мастер.

Более 12 лет в разработке ПО, последние 8 лет создает и руководит командами по разработке программного обеспечения.

С 2007 года обучает и внедряет подход Scrum в различных командах, проводит консультации по методологии Scrum и Agile-разработке, сертифицированный Scrum-мастер.

Кроме того, работает на различном уровне с командами для выявления и преодоления проблем в их работе, проводит тренинги по командной работе.

Алексей Кривицкий – 8 лет в сфере разработки программного обеспечения в ролях Developer (Java, .NET), TeamLead, ScrumMaster.

Три года назад создал группу AgileUkraine – украинское сообщество гибкой разработки, активно поддерживает его и представляет на международном уровне. Сертифицированный командный коуч, участник программы сертификации бизнес-тренеров Erikson Coaching International, Certified Scrum Master и Certified Scrum Practitioner.

Управляющий партнер компании SCRUMguides, консалтинговый бизнес которой сфокусирован на создании эффективных команд и построении процессов с использованием гибких подходов. Занимается коучингом проектных команд, бизнес – коучингом, читает тренинги по тематике гибкой разработки и управления проектами.

Николай Алименков – эксперт в разработке приложений на Java и управлении командами. Имея опыт разработки более 5 лет, уже более 3 лет Николай работает с Agile методологиями. На текущий момент практикующий технический лидер и Scrum Master. Имеет большой опыт в применении инженерных практик (TDD, CI, юнит тестирование, т.д.). Николай является автором тренингов и тренером по тестированию приложений, планированию, организации QA процесса, инженерным практикам.

Евгений Компаниец –  Работает программистом с 1999г.

С 2003 по 2005 работал как XP coach.

С 2005 работает в стартапах и проектах автоматизации для украинских заказчиков.

Адепт peer-based организаций.

Юзабилити эксперт.

Статьи по теме

• Запись он-лайн дискуссии "Спроси Agile-практика"
• Дискуссионная он-лайн панель "Задай вопрос Agile-практику"
• Интервью с Майком Коном
• Ближайшие мероприятия
• Пора отпусков и Scrum

© Тимофей Евграшин для The Improved Methods, 2010. | Permalink

И я задумалась, а как я относилась к своим руководителям? Честно говоря, не могу сказать, что я их не любила, нет. Свою трудовую деятельность я начинала едва мне исполнилось 18 лет, вот тогда я и узнала, кто такие «руководители». С тех пор у меня их было много, и все они были абсолютно разные, совсем не похожие друг на друга:

• отличные руководители, которых я безумно уважала и до сих пор считаю их Руководителями с большой буквы
• руководители, которые умели руководить проектами, но не умели руководить людьми
• были и те, кто хорошо строил отношения с людьми, но не умел наладить процесс
• были и такие, кто не умел ни того, ни другого, но хорошо создавал видимость своей работы.

Анализируя свой опыт и знания, полученные за эти годы, могу привести ряд ситуаций, которые влияют на нелюбовь к руководителям. Итак, когда же руководителей не любят:

1. Когда человек просто не нравится, по разным причинам.

2. Когда он постоянно придирается, даже по мелочам

3. Когда он допускает ошибки, и делает подчиненных в них виноватыми

4. Когда в сложных ситуациях, он отстаивает себя, а не свою команду

5. Когда у него плохое настроение, и он вымещает его на подчиненных

6. Когда беззастенчиво присваивает идеи подчиненных

7. Когда ставит нереальные задачи и планы

8. Когда заставляет делать подчиненных что-то неэтичное или противозаконное

Проанализируйте свой опыт. Давайте дополним список Я думаю, он многим пригодится, особенно начинающим руководителям.

Статьи по теме

• Как мы подбираем сотрудников
• Осторожно, подхалимство!
• Должен ли руководитель все знать?
• Может ли руководитель быть добрым?
• Офисные войны или Новая метла по-новому метет

© Мария Евграшина для The Improved Methods, 2010. | Permalink