• Новости киевского тренинга Happy PM

    Posted on November 30th, 2009 Александр Орлов 2 comments

    На прошедших выходных отгремел тренинг Happy PM в Новосибирске. Группа подобралась сверх-позитивная и активная. Давно не слышал столько вопросов. :) Надеюсь, другие группы не обидятся. Вообще, каждый тренинг уникален. И состав участников всегда уникален по-своему. НО в Новосибирске – это что-то. Я даже не устал после двух дней. :)

    Через полтора часа буду выступать в НГУ про карьеру в ИТ (возможно, выложу это выступление), а пока – новости тренинга Happy PM, который пройдет в Киеве 5-6 декабря:

    1. Тренинг пройдет в помещении УЦ Люксофт по адресу: Киев, ул. Радищева 10/14, БЦ <Ирва>, корпус Б, 2-ой этаж. Аудитория №15 (учебный класс №2). Карта: http://www.luxoft-training.ru/contacts/kiev.html

    2. 6-го декабря на дне, посвященном развитию карьеры, с гостевым спичем выступит Слава Панкратов, мой хороший друг и партнер, который за свои 28 лет успел сделать какое-то невероятное количество вещей. В том числе:

    P.S. Узнать, что такое тренинги Happy PM (программа, бонусы, отзывы участников, гости, расписание в вашем городе и пр.) вы можете здесь: http://www.happy-pm.com/blog/?p=3116

  • Отличается ли багтрекинг от тех. поддержки?

    Posted on November 30th, 2009 Александр Орлов 1 comment

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

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

    Есть две основных теории:

    1. Все вести в одной системе. Это может быть, к примеру DevTrack, Jira или что-то подобное. Разделение между обращениями пользователей и багами происходит на уровне имени проектов, каких-то конфигурационных настроек WorkFlow и т.п

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

    Какие имеются ограничения. В первую очередь, хотелось бы иметь бюджетное решение. Вбухивать бабки в систему а-ля BMC Remedy или HP OpenView никто не готов. Во-вторых, хотелось бы иметь решение, которое начало бы работать как можно быстрее. В третьих, хотелось бы иметь решение, которое было бы легко поддерживать.

    Что еще могу сказать. Как сам продукт, так и служба техподдержки довольно молоды и находятся на стадии становления. Клиентов пока не настолько много, чтобы техподдержка представляла собой что-то монументальное. Но уже достаточно, чтобы наколеночные решения не работали. О колл-центре пока речи не идет, о регистрации обращений через интернет – возможно, но 99% обращений поступает в виде телефонных звонков. Основные пользователи нашего продукта (не системы HelpDesk) – люди, от IT далекие. В HelpDesk вообще пользователям доступа давать не планируется. Всегда на входе прокси в виде нашего оператора хелпдеска. Когда говорится о возможности заведения инцидентов через интернет, имеется ввиду, что система может автоматически отправлять сообщения об ошибках, если произошло обрабатываемое падение.

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

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

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

    А что ты думаешь по этому поводу? Вы скажи свое мнение!

  • Тех лидов лучше посылать раньше. Но никогда не поздно.

    Posted on November 29th, 2009 Александр Орлов No comments

    От организаторов конференции с длинным названием “Разработка сложных систем и приложений с базами данных: инструменты, технологии, принципы“, куда рекомендовалось послать своих тех лидов, поступили печальные новости об окончании льготного периода регистрации.

    Теперь стоимость участия в этом мега-событии составляет 6900 руб. Однако, для читателей Happy PM, а также всех. кто догадается указать ключевое слово “happy PM” при регистрации, цена 5900 руб. Тянуть с посылкой своих тех лидов все равно не рекомендуется. :)

    Напомню, что событие предстоит действительно любопытное – коллеги из Amazon и Microsoft будут раскрывать всякие полезные темы. Кроме всего этого в числе подарков участникам – сертификат на бесплатное получение лицензионного дистрибутива Visual Studio 2010 Professional.

    Я хочу послать своих тех лидов на правильную конференцию!

  • IT Jam в Киеве: 5 декабря

    Posted on November 28th, 2009 Александр Орлов No comments

    (участие бесплатное при условии предварительной регистрации)

    Как и сообщалось, в связи с эпидемией свинского гриппа пришлось перенести совершенно замечательное событие IT Jam на 5-е декабря. Что означает, что и я сам туда тоже зайду после первого дня киевского тренинга Happy PM. Вероятно, попаду уже на вечеринку. :)

    От организаторов IT Jam’а поступили новости о деталях проведения:

    Крупнейшая конференция программистов IT JAM 2009 пройдет 5 декабря

    Конференция, как и было запланировано, состоится в Киеве, в выставочном центре «АККО» Интернешнл. Организатором мероприятия является компания Ciklum.

    Компания обозначила содействие развитию в Украине узко-специализированной SWD экспертизы стратегической целью на 2009 год.

    В этом году у мероприятия новый формат: тематические мини баркемпы + панельная дискусия + вечеринка.

    Основная идея  конференции - peer-to-peer обмен знаниями и опытом по следующим направлениям:

    ? Dynamic Programming Languages (Ruby on Rails, Python, Perl)

    ? Mobile Development (iPhone, Android, Blackberry)

    ? Agile (Scrum, XP, Kanban)

    ? RIA (Flash, Silverlight, Flex)

    ? CMS (Drupal, EPiServer, Joomla)

    После докладов будет проведена панельная дискуссия с топ-менеджерами и владельцами ведущих IT компаний.

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

    По традиции IT Jam завершится вечеринкой: участников ждет неформальное общение с коллегами, музыка, пиво и хорошее настроение!

    В связи с тем, что конференция была перенесена на более позднюю дату, появились изменения в расписании – в частности, добавились новые докладчики. Вы можете ознакомиться с обновленным  расписанием на сайте IT Jam.

    Участие в конференции – бесплатное. Для получения пригласительного билета, необходимо зарегистрироваться на сайте http://it-jam.ciklum.net.

  • Истории Успеха: выводим сотрудников из депрессии :)

    Posted on November 27th, 2009 Александр Орлов No comments

    Проект Happy PM открывает новую рубрику – Истории Успеха. В этой рубрики будут публиковаться выдержки из отчетов участников наших тренингов. Публиковаться они будут, естественно, только с разрешения самих участников.

    К сожалению, многое нельзя опубликовать по причинам конфиденциальности. Во многих случаях я не буду упоминать имени человека по той же причине. Иногда буду вставлять пропуски, чтобы напустить туману. :) Ну да ладно. Будем публиковать то, что можно.

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

    Кстати, возможно, кто-то помнит историю, рассказанную Кариной Львовой, которые (Карина вместе с историей) как раз и положили начало рубрике Истории Успеха. С тех пор многое поменялось, футболки за истории теперь не выдаются :) , но истории, тем не менее, будут появляться чаще.

    Итак, передаю слово сегодняшнему рассказчику, точнее, рассказчице ():

    Часть первая. Что изменилось в моей работе после тренинга

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

    Теперь по порядку  об изменениях.

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

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

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

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

    Часть вторая. Ответы на вопросы с тренинга.

    Как вывести сотрудника из квадрата «блин»

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

    1. Во первом случае один из ведущих разработчиков совершенно потерял интерес к проекту, на котором работал год. При чем, как выяснилось, проект ему бросать не хотелось, но и работать  только на нем он уже не мог. Поэтому мы его оставили на первом проекте как код ревьюира ( так как знал он его лучше остальных). И поставили его ведущим разработчиком на другой проект более высокой сложности и с новыми технологиями. Теперь он с радостью помогает и старой команде, когда есть такая необходимость, и на новом проекте замечательно работает.
    2. Второй способ я еще только планирую попробовать  в ближайшем будущем. Я знаю, что один из моих разработчиков виндоус приложений очень интересуется системным программированием на С++. При этом в рамках текущего проекта он уже сделал все, чтобы повысить его стабильность и качество. Все сложные задачи в рамках проекта уже решены. Сейчас я планирую вывести его из проекта и послать на С++ задачу.
    3. Третий способ вернуть интерес - изменить круг обязанностей. Например, если опытный  разработчик на проекте потерял  интерес, можно расширить его  круг ответственности - поставить  под него новичка. Тогда он будет  с удовольствием передавать свои навыки и  знания. Это имеет несколько  преимуществ - хорошая передача знаний в коллективе; повысившаяся самооценка и чувство востребованности человека, который только что казалось бы потерял интерес к работе.

    Часть 3. Как работать с разными  типами людей

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

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

    Есть у меня в  команде и Integrator, который всегда боиться кого-то обидеть, показаться кому-то грубым. Он не может попросить команду выйти на работу в выходной, потому что боится, что все будут думать, что он бессердечный и несправедливый. Единственный способ, который я нашла на данный момент – пытаться повышать его собственную самооценку в моменты, когда ему надо принять жесткое решение. Я объясняю ему, что его же команде нужно ощущение значимости, понимание, что если они выйдут в выходные – так это потому, что их работа действительно ценна. Главное создать для него условия, в которых он будет видеть, что никого не обижает.Ну вот и все! Извиняюсь, если пропустила какие-то из вопросов, оставленных на домашнее задание. Постаралась осветить все. :)

    P.S. Хотите принять участие в тренингах Happy PM? Узнайте, когда они будут в вашем городе и записывайтесь!

  • Мастер-группа проекта Happy PM

    Posted on November 26th, 2009 Александр Орлов 8 comments

    Как многие, наверное, знают, перед каждым тренингом я предупреждаю всех участников, что буду хотеть от каждого из них отчет о внедренных навыках и проделанных действиях. Большинство народа (50-80%) прислушивается и таки присылает (возможно, это я довольно убедителен в своих просьбах :) ).

    Я подумал, что было бы правильно объединить тех, кто доказал свою способность и приверженность практическим действиям – объединить в закрытый клуб. Несколько дней назад этот закрытый клуб стартовал под названием “Мастер-группа проекта Happy PM”.

    Внутри мастер-группы будут публиковаться:

    • закрытые материалы проекта Happy PM
    • записи тренингов Happy PM
    • выступления гостей на тренингах Happy PM
    • кейсы и инструменты
    • откровенные разговоры с экспертами и синьор менеджерами индустрии

    Как попасть в мастер-группу Happy PM? Очень просто:

    • пройти один из наших тренингов
    • в течение трех недель после этого внедрять и пробовать то, что мы там проходим
    • написать отчет о проделанных действиях на info@happy-pm.com

    После этого вы получите приглашение вступить в мастер-группу. Предваряя вопросы:

    • В мастер-группу нельзя попасть за деньги (по крайней мере, пока :) )
    • В мастер-группу нельзя попасть по знакомству

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

    Если Вы прошли один из наших тренингов, прислали отчет, но пока не получили приглашения – напишите, пожалуйста, на info@happy-pm.com и мы исправим это недоразумение.

  • SPMGuild: бесплатный вебинар по Lean, 4 декабря

    Posted on November 26th, 2009 Александр Орлов 3 comments

    Наше общее с коллегами-экспертами предприятие “Гильдия менеджеров программных проектов SPMGuild” начинает проведение бесплатных вебинаров.

    Первый вебинар пройдет 4-го декабря с 13:00 до 14:30. Вебинар будет посвящен модному в последнее время слову Lean. :) Выступать с комическими куплетами будет президент гильдии Сурен Самарчян, который по совместительству является руководителем  департамента управления проектами в компании Иннова Системс.

    Записываться нужно тут: https://www2.gotomeeting.com/register/176042747 Чуть ниже – наш официальный анонс.

    Гильдия менеджеров программных проектов (www.spmguild.org) приглашает Вас 4-ого декабря в 13:00 принять участие в вебинаре на тему «Лин» – подходу к организации  работы, используемому такими компаниями как Toyota, Boeing, Intel и другими мировыми лидерами в своих отраслях. В России на Лин недавно начали переходить такие гиганты как «Сухой», «Камаз», «Сбербанк» и другие. Более того, эти компании не просто используют данный подход, а считают его одним из нескольких ключевых элементов своей стратегии. В софтверной индустрии Лин подходы используют Google, Nokia, Yahoo, British Telecom, IBM, Microsoft и многие другие.

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

    1. Основные принципы Лин

    2. Какие компании используют Лин и какие результаты были получены

    3. Стандартные классы потерь

    4. Канбан

    5. Картирование потока добавления ценности для пользователя

    6. Переработки, вариабельность и их влияние на скорость выпуска продуктов

    7. Лин для разработки инновационных продуктов

    8. С чего начать при внедрении Лин

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

  • Минск в семинарах осенью 2009-зимой 2010

    Posted on November 25th, 2009 Александр Орлов No comments

    Сергей Полаженко, минский организатор тренингов Happy PM и мой хороший товарищ, продолжает и углубляет тему семинаров в столице Беларуси. Вот что он готовит:

    Компания “Лаборатория тестирования” (www.sqalab.ru), известная в РБ рядом проектов, таких как:

    • Sofware Quality Assurance Days IV (2008 Минск);
    • Software Engeneering Forum (2009, Минск);
    • SECR(C) 2009 & SQA Days VI (Москва) ;

    Планирует совместно с ООО “Сталкер-Медиа” проведение ряда ИТ-семинаров (тренингов) в Минске. Это будут семинары белорусских и зарубежных авторов, признанных специалистов в своей области.

    Денис Петелин (Минск, www.agile.by, www.beagile.by):

    30-ое ноября: Управление рисками в разработке ПО

    http://posuti.info/publ/spm_06_upravlenie_riskami_v_razrabotke_po/44-1-0-265

    Алексей Баранцев (Москва, www.software-testing.ru):

    17 января: Тестирование методом свободного поиска (exploratory testing)

    http://posuti.info/publ/testirovanie_metodom_svobodnogo_poiska_exploratory_testing/44-1-0-308

    18 января: Автоматизация функционального тестирования веб-приложений: Selenium + Selenium RC

    http://posuti.info/publ/avtomatizacija_funkcionalnogo_testirovanija_veb_prilozhenij_selenium_selenium_rc/44-1-0-309

    19 января: Обзор бесплатных инструментов тестирования ПО

    http://posuti.info/publ/obzor_besplatnykh_instrumentov/44-1-0-310

    Александр Орлов (Санкт-Петербург, www.happy-pm.com)

    13-14 февраля: Управление командой разработчиков и Карьера менеджера.

    http://www.happy-pm.com/blog/?p=3116

    Так же хотели бы сообщить, что 5-го декабря  при нашей поддержке, состоится экзамен на получение ISTQB сертификата Foundation и Advanced Level.
    Регистрация доступна на сайте Белорусской Национальной коллегии тестировщиков:
    http://www.bystqb.org/index.php?option=com_fabrik&view=form&fabrik=2&random=0&Itemid=17

  • Продажа второго монитора начальству

    Posted on November 25th, 2009 Александр Орлов 7 comments

    Результаты опроса про количество мониторов у сотрудников немного удручают. На текущий момент в опросе поучаствовали больше 200 человек. Что мы видим:

    • 59% – один монитор
    • 29% – два монитора
    • 2% – три и более мониторов

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

    Почему же оно до сих пор так? По моим наблюдениям, причина ровно одна: менеджер не выбил своей команде вторые мониторы. А почему не выбил? Тут обычно видятся две подпричины:

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

    Поговорим сегодня про первую причину (вторую оставим на потом :) ). Ну, действительно, с какого такого перепуга начальство должно выделять денег? Покупка мониторов – это всегда затраты. Для чего, зачем – вот это нужно начальству как-то объяснить. И тут есть два рабочих способа.

    Способ №1. Вычисление ROI. Мы считаем, сколько времени инженер тратит на переключение между окнами. Предположим, у нас получается 20 минут в день. 20 минут в день – это 440 минут в месяц, говорим мы. А это, подумать только! семь с лишним часов рабочего времени в месяц. В год человек простаивает почти 12 дней. Монитор стоит дешевле. Давайте, купим ему монитор – это окупится уже в первый год!

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

    (Заметим, что Сергей Мартыненко когда-то давно в своей статье приводил еще больше плюсов от количества мониторов.)

    Способ №2. (Этот способ мне недавно подсказала слушательница на одном из корпоративных тренингов. И я пришел от него в восторг. :) ) Тут тоже нужна подготовка. Берем две детские картинки из серии “найди 10 отличий”, например вот такую. Одну картинку распечатываем на одной стороне листа. Вторую на второй. После чего происходит примерно такой диалог:

    - Саша, ну вот объясни мне, зачем твоим ребятам второй монитор? Ведь нормально же работают на одном. Уже давно работают.

    - Нормально? Я вот вам сейчас покажу…

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

    Этот способ может подействовать на начальников, которые в специфике процессов разработки и отладки понимают не очень. Для многих сам компьютер – уже роскошь. Мы еще помним времена, когда 486-й с 15-дюймовым монитором был предметом зависти! А тут два монитора…

    Надеюсь, способы помогут кому-нибудь таки продавить идею омониторивания. :)

    P.S. Кстати, коллеги, если кто-то использовал другие интересные способы – поделитесь. Думаю, многим будет интересно.

  • Цитата недели (Джо Мараско)

    Posted on November 24th, 2009 Александр Орлов No comments

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