The Improved Methods

Открытые тренинги в Днепропетровске, Киеве и Харькове

Тимофей Евграшин — Tue, 07 Sep 2010 06:00:49 +0000

Наконец-то устаканилось расписание моих открытых тренингов до конца этого года. Приглашаю всех заинтересованных на тренинги, которые пройдут в Днепропетровске, Киеве и Харькове.

В каждом городе пройдет по 2 тренинга:

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

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

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

Для участников прошлых тренингов – 15% скидка, также предусмотрены групповые скидки (от 3-х человек) – по запросу.

Регистрируйтесь заранее, так как количество мест ограничено.

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

Расписание:

Тренинг по управлению требованиями в стиле Agile «Говорим с заказчиком на одном языке»

23 октября 2010 года – город Днепропетровск. Регистрация на тренинг в Днепропетровске

13 ноября 2010 года – город Харьков. Регистрация на тренинг в Харькове

20 ноября 2010 года – город Киев. Регистрация на тренинг в Киеве

Тренинг развития навыков эффективной работы в команде “Как из того что есть сделать команду”

27 ноября 2010 года – город Днепропетровск. Регистрация на тренинг в Днепропетровске

4 декабря 2010 года – город Киев. Регистрация на тренинг в Киеве

11 декабря 2010 года – город Харьков. Регистрация на тренинг в Харькове

Agile бизнес игра на IT-Jam

Тимофей Евграшин — Sun, 05 Sep 2010 11:39:56 +0000

Польза от практических игр и симуляций несомненна. Человек запоминает до 90% из практического опыта, полученного в упражнениях, и лишь 10% из услышанных теорий. Бизнес игры дают нам возможность поэкспериментировать и поучиться в безопасных условиях. Применять новые идеи в реальности всегда легче, когда знаешь, какие результаты могут получиться.

Мы снова сделаем это! В рамках яркого и интересного события IT-Jam 2010 найдётся место и для Agile бизнес игры «по крупному» . В Харькове 11 сентября меня пригласили провести “The Business Value Game” – игру, которая помогает понять, как выпускать нужные продукты с нужными функциями и в нужное время. Эта игра позволяет разработчикам, Скрам Мастерам, бизнес-аналитикам, менеджерам и бизнесменам выработать подходы к оценке той «бизнес ценности» о которой часто говорят, хотя редко кто может её посчитать.

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

Всего будет участвовать до 10 команд по 7 человек, так что количество мест ограниченно. Я и группа ассистентов поможет каждой команде организовать «выпуск продукта» в течение 6-ти итераций. Каждая команда будет решать, какую стратегию выбрать, чтобы получить максимальную прибыль. И конечно, мы все будем делиться опытом во время и после игры, так что в любом случае вы выйдете из игры с новыми идеями и впечатлениями.

Итак, если вы хотите присоединиться к нам 11 сентября в Харькове, то регистрируйтесь на сайте IT-Jam.

Как порадовать себя или очумелые ручки

Мария Евграшина — Thu, 02 Sep 2010 16:50:39 +0000

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

Во-первых, такой творческий труд очень полезен

Во-вторых, вы можете себя порадовать чем-то прекрасным hand-made, а это дорогого стоит

И в-третьих, иногда надо отвлечься от рутины, или просто отвлечься, чтобы в голову пришли новые мысли

А предлагаю я сделать календарь – один или несколько, для себя лично или для кого-то еще, самостоятельно или с группой товарищей.

1. Календарь с пупырышками

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

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

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

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

2. Календарь – мотивационный

Тут уже больше придется повозиться.

Возьмите штук 10-31 (у кого на сколько хватит сил) бумажек и напишите для себя что-то вдохновляюще приятное (это кстати можно сделать и с командой на каком-нибудь мотивационном командном тренинге или просто в группе)
Сделайте 31 конвертик и пронумеруйте их. В некоторые (или все) вложите записки
Возьмите веревку и прищепки и прикрепите конверты к веревке. Каждый день снимайте конвертик и читайте, что там написано. Так, кстати, можно себя проверять – успели ли вы к этой дате сделать то, что хотели

3. Календарь творческий

Сегодня многие увлекаются фотографией, если вы один из таких людей, а если у вас еще коллеги такие же фанаты, то вы можете сделать кучу фотографий с цифрами и не только. Отыскать их сложно, но это того стоит. Понятно, что цифры, которые надо фотографировать, должны быть от 1 до 31, кроме этого вам понадобятся фотографии с днями недели. В итоге у вас может получиться весьма уникальный календарь такого вида:

Идея Sandy Weisz, попробуйте, должно получиться очень красиво. Не уверена, что это будет очень удобный календарь, зато это будет очень неординарно.

4. Календарь простой

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

На них можно писать самые важные мероприятия или дела в этот день, а уходя домой с работы, отклеивать бумажку и с чувством выполненного долга порвать ее выбросить

Так что, даже в самых скучных вещах можно найти что-то увлекательное

Оптимизация плоскости или что общего у Agile и Lean

Тимофей Евграшин — Tue, 31 Aug 2010 05:30:22 +0000

Не секрет, что в современном мире, мы часто сталкиваемся с тем, что популярные названия становятся брендами. Слово Agile (с заглавной буквы) тоже не исключение и сейчас можно встретить описание практически любой практики с приставкой «Agile» спереди. Также не секрет, что из-за того, что люди редко глубоко вникают в концепции стоящие за названием, то мы часто путаем популярные бренды, особенно те, которые не связаны с каким-то определенным и осязаемым товаром.

Так частым примером недопонимания является вопрос типа: «А разве Lean и Agile это не одно и то же?». Если коротко – нет.

Как я уже говорил, если не смотреть на концепции, то легко ошибиться, так как оба подхода преследуют общую цель: часто выпускать готовый продукт и постоянно улучшать качество продукта (да и самих практик в конкретной команде). Более того, практики Agile зачастую поддерживают принципы Lean и наоборот. В тоже время это не одно и то же, нет. «Бережливое производство» (так переводят Lean) имеет гораздо более широкий фокус и зачастую подразумевает, что мы не сосредотачиваемся только на проблемах одной команды разработки, а смотрим на всё подразделение разработки ПО или даже на всю организацию в целом.

Впервые о «Lean for Software Development» (т.е. о «Бережливой разработке программного обеспечения») заговорили Мэри и Том Поппендик в одноименной книге, которая увидела свет в 2003 году. Как известно, «Agile сообщество» само-идентифицировалось и развивалось с 2001, поэтому не удивительно, что Мэри и Том стали почти обязательными гостями на любой Agile конференции. Кстати, предстоящая Agile Eastern Europe не исключение и если посмотреть на список докладчиков, то ключевой доклад Мэри Поппендик задает тон всей конференции.

В своей книге Поппендики озвучили 7 принципов «Бережливого производства» (Lean) в приложении к разработке ПО и даже в какой-то мере провели параллели с Agile.

Исключение затрат. Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.

Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

Предельно быстрая доставка заказчику. Короткие итерации.

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

Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно».

Кроме принципов, они описали еще и 22 инструмента, которые собственно и помогают нам внедрять концепции на практике. Также как мы используем, например, практики из Scrum методологии, чтобы внедрять Agile, также практики Lean помогают нам делать весь наш процесс разработки программного обеспечения чуть более «бережливым» или «плоским».

Уверен, что я еще не раз вернусь к теме Lean на страницах нашего блога и вы можете подписаться на наш RSS, чтобы не пропустить практические рекомендации и полезные советы. А чтобы не рассказывать о том, в чем сам разбираюсь не досконально, я решил пойти на мастер-класс Мэри и Тома Поппендиков, который состоится в рамках конференции AgileEE. Хотите узнать все и сразу? Присоединяйтесь .

Мозговой штурм в художественном стиле

Мария Евграшина — Sun, 29 Aug 2010 15:32:56 +0000

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

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

«Картинки-до»

Основные правила:

Группа до 7 человек
Перед встречей каждый человек собирает по 3-5 фотографий, картинок (вырезанных из журналов, распечатанных из интернета). Картинки должны как-то быть ассоциированы с предметом мозгового штурма. Перед встречей все картинки собираются вместе.
На большом листе бумаги описать в 2-3 словах предмет мозгового штурма
Каждому человеку дается лист бумаги, несколько картинок и 5 минут времени, чтобы он написал все ассоциации, как изображение относится к предмету мозгового штурма
Потом изображения меняются между участниками.
В конце собираются все идеи, группируются и обсуждаются.

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

«Картикни во время»

Основные правила:

Тоже небольшая группа
Каждому выдаются небольшие листики формата ¼ А4
У каждого человека карандаш своего цвета
На большом листе бумаги описать в 2-3 словах предмет мозгового штурма
Выделяется 40-60 мин времени, чтобы каждый нарисовал 30 картинок на отдельных листиках, которые у него ассоциируются с темой мозгового штурма. Понятно. Что эти картинки из серии «каляки-маляки». Когда мы наспех пытаемся кому-то что-то объяснить на клочке бумаги
По окончании все художества собираются в единую стопку, перемешиваются, выбираются самые интересные. После чего их крепят на основном листе бумаги
Проходит обсуждение с основной генерацией идей по рисункам

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

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

Творческих вам мозговых штурмов

Когда и как выбирать пилотные команды (часть 2)

Тимофей Евграшин — Fri, 27 Aug 2010 17:22:09 +0000

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

Вне зависимости от того, была ли возможность подобрать людей в Scrum команду, важно правильно выбрать проект, который вы будете делать с использованием Scrum. Вторым важным фактором выбора «пилотной» команды, является правильный выбор проекта.

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

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

1. Длина проекта

Оптимальный срок для пилотной команды, когда она задействована в выпуске (релизе), продолжительностью в 3-4 месяца. Если проект или релиз длится меньше, то сложно увидеть выгоды, а для проектов более 6 месяцев будет много шансов отклониться от общей цели на последних месяцах, при том, что долгое время наблюдались выгоды от использования гибких методов и предпринятых изменений.

Если говорить о командах, которые уже практикуют гибкие методы некоторое время, то, как рекомендацию для них, можно указать наличие регулярных дедлайнов каждые 3-4 месяца. Даже если идёт разработка проекта (выпуска/релиза) длинной в год и более, то важно проводить полную стабилизацию продукта как можно чаще. Для этого важно найти баланс между усилиями на подготовку к выпуску (системное/финальное) тестирование, и между важностью получения обратной связи от заказчика и пользователей, с тем, чтобы конечный выпуск уже учитывал все нужды и обеспечил максимальное состояние готовности.

2. Размер

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

3. Важность проекта

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

4. Вовлеченность бизнеса

Главным благоприятным фактором является всесторонняя поддержка идеи изменить имеющиеся подходы. Идеально, если представители заказчика уже осознали необходимость менять существующие подходы, так как старые доказали свою несостоятельность. Как минимум они должны понимать, что они могут получить (наглядность, регулярность) и какие роли им придётся исполнять для взаимодействия с командой (Владелец Продукта или Заказчик, который договаривается с Владельцем Продукта).

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

Когда и как выбирать пилотные команды (часть 1)

Тимофей Евграшин — Tue, 24 Aug 2010 08:00:10 +0000

Если у вас относительно небольшая компания по разработке софта или просто вы ведёте несколько проектов у одного заказчика, то наверняка вы сталкивались с опасениями при мысли о внедрении Agile подходов в вашу работу. Редко какая компания может позволить себе поменять «всё и сразу». Хотя, уже многие компании достигли состояния «так дальше жить нельзя» и активно смотрят по сторонам в поисках простых и предсказуемых методов управления проектами. Возможность видеть реальную ситуацию на проекте, адекватно предсказывать время поставки и отслеживать долгосрочные планы – это то, что заставляет многих менеджеров все чаще и чаще смотреть на существующие гибкие (Agile) методы управления проектами и в частности Scrum методологию, как один из простых и в тоже время ясно описанных процессов.

За последние несколько месяцев я уже несколько раз столкнулся с необходимостью выбирать подопытных кроликов «пилотную» команду, которая начнёт использовать Scrum подход к управлению проектом. Такая команда обычно одна из группы команд, и остальные участники смотрят на их опыт, чтобы получить практические ответы о том «как это будет у нас». Опыт «пилотной» команды можно использовать как модель для других команд, или же наоборот, члены «пилотной» команды могут принять участие в разных командах и делиться уже своим практическим опытом на местах.

Понятно, что от правильного выбора «пилотной» команды будет зависеть многое. Лично я вдохновлялся идеями Майка Кона из книги «Succeeding with Agile», пропущенными через мой личный опыт работы в Скрам-командах.

Самым критическим фактором для такой команды будут, конечно же, люди. Идеально, если у вас есть возможность сформировать новую команду под проект, который вы собираетесь делать с использованием Scrum подхода. Даже если вы не собираете новую команду, то советую вам обратить внимание на наличие в команде следующих типов людей:

Фанаты Scrum – такие люди будут следить за правильным использованием методологии, объяснять, как вы работаете заказчикам и другим заинтересованным лицам.
Оптимисты – эти люди могут ясно понимать, что «как раньше жить нельзя», в тоже время, они могли быть не столь активны, убеждая всех в необходимости внедрения новых методов. Скорее всего, это будет большинство членов команды.
Адекватные скептики – такие люди обязательно нужны команде, чтобы время от времени задавать вопросы типа: «а нужно ли это делать?» или «а какие выгоды мы получим от таких изменений?». Слово «адекватные» тут играет важную роль, так как я подразумеваю, что эти люди не против изменений, просто они предпочитают «семь раз отмерять».
Зачастую, после того, как процесс налаживается, такие люди становятся самыми лучшими сторонниками распространения Scrum или других Agile подходов на всю организацию, потому что они видели и понимают, как это работает и какие даёт выгоды. Более того, эти люди одни из лучших евангелистов, так как их репутация здравомыслящих людей стоит гораздо больше, чем толпа фанатов с горящими глазами

Очень важно постоянно работать с ожиданиями всех лиц, участвующих во внедрении новой методологии, и своевременно их корректировать. Это могут быть заказчики (как и в случае аутсорсинга, так и в случае локальной разработки); менеджмент проекта или компании (которые от нового подхода ожидают ответов на свои вопросы); участники Scrum команды; соседние команды и т.п. Также важно постоянно анализировать текущую ситуацию на проекте и даже проводить расширенные ретроспективы с участием членов других команд и представителей менеджмента разных уровней.

Ну и не забывайте, что это всего лишь «пилотный» проект и право Scrum команды на ошибку – одна из неотъемлемых частей такого подхода. И команда, и остальные должны это понимать и принимать, чтобы избежать «страха провалиться» и тем самым гарантированно все испортить . «Пилотная» команда помогает понять, что и как нужно менять в организации, даже если конкретный проект, над которым она работала, оказался не самым удачным.

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

Помогают ли ваши цели сделать лучше ваше настоящее?

Мария Евграшина — Thu, 19 Aug 2010 19:59:50 +0000

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

И тогда возникают мысли: “И зачем мне эти цели? Моя жизнь и так очень сложна, я сам себе ее еще и усложняю. Лучше отказаться от целей и жить, как живется.” Ну что же, это тоже жизненная позиция, и иногда действительно стоит остановиться, чтобы что-то понять и осознать.

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

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

Рецептов и советов тут нет. Каждый выбирает сам для себя:

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

– у каждого будет свой путь. Самое главное – найти его и облегчить свое сегодня, сделать его приятным и вдохновляющим

Софт за 24 часа – как это было

Тимофей Евграшин — Mon, 16 Aug 2010 14:47:31 +0000

Для всех, кто участвовал в проекте “Софт за 24 часа”, эти выходные бесспорно прошли напряженно и плодотворно. Если вы не следили за тем, что происходило в течение сумасшедших суток, то очень рекомендую посмотреть, что же мы делали, на сайте проекта.

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

Что же у нас получилось?

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

Итак, вот собственно реализованные проекты:

Twitt opinions: “Прочирикай, что ты думаешь” – именно так “переводят” авторы название web-приложения, которое обеспечит на конференциях и семинарах возможность получить отклик аудитории в виде диаграмм, а не просто в виде потока в реальном времени. Учет реакции аудитории поможет докладчикам, принеся им внятные оценки слушателей.
Zацени: Каждый, кто объяснял хоть раз друзьям и просто знакомым почему он купил такой фотоаппарат или мобильный телефон, как выбирал телевизор или принтер, несомненно оценит возможности нового проекта. Простое голосование за гаджеты и столь же простой доступ к накопленным оценкам, подключение к популярным социальным сервисам Twitter и Facebook упрощают быстрый старт и “первоначальное накопление” оценок.
Happy Road: Подобно тому, как отправляясь в путь мы все чаще проверяем в онлайн-сервисах пробки на дорогах, использование нового сервиса станет привычным способом выбора дороги, которая порадует путешественника. На карте уже привычного сервиса Google maps путешественник найдет подсказки и о приятных неожиданностях, и о неприятностях, которые могут поджидать вас в пути.
Финик: Команда, создавшая свое приложение в весьма конкурентной области персональных финансов, не только представила разработанную за 24 часа функциональность, но и продуманный “нейминг”, и соответствующий ему фирменный стиль, уже воплощенный в дизайне web-приложения. Вы уже догадались? “Финик” это “ФИНансы И Ко”.
SimRim: SIMple RIsk Management – название приложение говорит само за себя: рассчитанный на начинающего руководителя проектов web-сервис поможет увидеть с какими рисками может столкнуться проект и своевременно принять ответственное решение.

Пробуйте, тестируйте, оценивайте с помощью наших же сервисов Zацени и Twitt opinions и в конце недели мы опубликуем обзор ваших мнений, чтобы решить как дальше помочь каждому проекту.

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

www.youtube.com/watch?v=jXVqyQgDfDo

www.youtube.com/watch?v=PQcOLrFWMSA

www.youtube.com/watch?v=VEiqf1bOoxg

www.youtube.com/watch?v=jtb3NvRSGHo

А это ролик про нас

www.youtube.com/watch?v=S6mveu0q-q0

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

Разговоры тет-а-тет в командной работе

Мария Евграшина — Thu, 12 Aug 2010 15:20:27 +0000

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

С чем это связано? Причин может быть много:

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

И так далее…

Есть и другие случаи, когда руководитель признает нужность таких бесед и проводит их весьма формально, забывая, что основная задача таких бесед – дать понять подчиненному, что он будет услышан, более того его хотят услышать. Формальные же беседы из серии «Ну расскажи как у тебя дела? Все нормально? Ну и хорошо» – это не то что не помогает, а создает еще больше причин для недоверия подчиненных своему руководству.

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

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

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

Приведите свой пример, похожий на проблемную или замалчиваемую ситуацию, опишите свои эмоции и мысли в той ситуации
Попросите собеседника рассказать о ситуации больше, попробуйте узнать детали, углубиться внутрь проблемы/ситуации
Узнайте его чувства-мысли по поводу какого-то вопроса, спросите его, как бы он поступил на вашем месте или на месте коллеги
Узнайте, на основании чего человек делает те или иные выводы
Используйте секреты открытых вопросов
Воспользуйтесь советами для сложных разговоров
Обратите человека в ситуацию «здесь и сейчас». Например, он говорит: «Никому не нужны мои советы». Вы можете спросить: «Как вы думаете, мне тоже не нужны ваши советы? Если вы помните, всего пару минут назад я просил вашего совета по такой-то ситуации»
Иногда человека нужно выдернуть из комфортной зоны, чтобы найти «корень проблемы»

Помните, все, что говорит человек, он говорит о себе, но не всегда это понимает. Понять и направить человека, помочь ему справиться с его трудностями – задача непростая, она требует постоянного оттачивания мастерства. Поэтому чем быстрее вы начнете проводить беседы со своими коллегами, и чем чаще вы будете это делать, тем у вас больше шансов научиться красиво и грамотно строить разговор; услышать проблемы подчиненного и помочь ему найти их решение; стать талантливым руководителем

И в завершение я приведу пример, иллюстрирующий, как важно обращать внимание на людей, которые находятся под вашим началом. Хоть я и участвовала в таких разговорах в качестве подчиненной, и сама проводила такие беседы в качестве руководителя, я приведу пример из своего детства. Когда я училась в 5-ом классе (а это было в конце 80-х, совок, пусть и перестроечный, но совок), к нам в школу пришел молодой директор. И наша школа превратилась в лицей. Один раз на перемене я сидела в коридоре на подоконнике, уминая бутерброд. Проходя мимо меня, директор сел рядом со мной и начал меня расспрашивать: как мне учится, что хорошо, что плохо и кучу всего еще разного. Я ему много чего рассказала. Сказать, что для меня это был шок – это не сказать ничего. Мы не были знакомы лично с директором, он не вел у меня никаких предметов, я для него была обычной ученицей его лицея, который он только начинал отстраивать. Так что когда большой человек обращает на нас и наши проблемы внимание – это очень приятно, поверьте

The Improved Methods

Открытые тренинги в Днепропетровске, Киеве и Харькове

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

Agile бизнес игра на IT-Jam

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

Как порадовать себя или очумелые ручки

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

Оптимизация плоскости или что общего у Agile и Lean

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

Мозговой штурм в художественном стиле

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

Когда и как выбирать пилотные команды (часть 2)

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

Когда и как выбирать пилотные команды (часть 1)

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

Помогают ли ваши цели сделать лучше ваше настоящее?

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

Софт за 24 часа – как это было

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

Разговоры тет-а-тет в командной работе

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