• Книги для менеджера на каждый день: 9 книг, как раз на неделю :)

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

    Многие из вас, наверняка, читали нашу Черную книгу менеджера.

    Если помните, в конце книги, мы обещали выпустить Белую книгу, но целый год у нас никак не удавалось собраться с силами, выкроить время и выполнить обещанное. Где-то в мае я ее таки написал, но то, что получилось, было нами забраковано за излишнюю механистичность и недостаток вдохновляющих историй. :)

    И вот не так давно, ребята из нашей команды пошутили, что книга на самом деле… давно написана! И написана она вашим покорным слугой за несколько лет его работы над проектом www.happy-pm.com, просто лежит эта Белая книга в архивах, разбросанная на разным категориям сайта, местами не вычитаная, местами не отредактированная, не собранная. Посмотрев на это дело внимательно, было решено собрать Белую книгу из самых разных постов на happy-pm.com, разбить по понятным людям категориям, удобным для чтения, и выложить для всех.

    В итоге получилась не одна книга, а небольшая книжная полка для менеджера из 9-ти коротких книг по разным темам. Интересно, что по размеру Белая книга получилась примерно в 7-9 раз больше Черной книги, но, наверное, это и правильно: все-таки наш мир не состоит из негатива, как могло показаться после прочтения Черной книги менеджера.

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

    «Одна задача решается, примерно, минут за 20. Вот вам 5 задач, как раз на час».

    Вот и у нас получилась книжная полка, каждую книгу в которой легко можно прочесть и переварить за день. Вот вам 9 книг, как раз на неделю :)

    • Карьера
    • Общение
    • Деньги
    • Делегирование, принятие решений, отчеты
    • Собеседования, рекрутинг
    • Лидерство
    • Совещания
    • Публичные выступления
    • Как писать письма

     

    Получить доступ ко всем книгам (бесплатно)!

  • Программа Стратоплан-2012: планируй свое развитие на 2012 прямо сейчас!

    Posted on December 6th, 2011 Александр Орлов No comments

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

    Так вот, (гремят фанфары) программы всех тематических Клубов Программы-2012 опубликованы:

     

    Отдельной страницей ведущие Клубов Программы-2012: http://www.stratoplan.ru/speakers/

    Друзья, напоминаем, что на текущий момент участие в одном Клубе стоит $600, в двух Клубах – $1100, в трех – $1500. И если вы хотите инвестировать в собственное развитие и карьеру – делайте это прямо сейчас. работа начнется уже 1-го февраля 2012.

    Если вы думаете, что такое обучение может быть полезно не только вам, но и другим вашим коллегам в компании – расскажите об этом своему начальнику и/или HR’ам, чтобы они трезво оценили свои потребности в обучении и заложили нужные цифры в бюджет.

    Спасибо и будем рады видеть вас в наших клубах!

    Слава Панкратов, Александр Орлов
    Команда Стратоплан.ру

  • Что случилось с тестировщиками 2: взгляд внутрь себя

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

    Мы со Славой Панкратовым продолжаем разбираться с ведущими тестировщиками нашей отрасли в том, что же случилось с тестировщиками?

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

    Алексей Лянгузов: 11 лет в тестировании, tech lead команды тестирования в Oracle, до этого работал в TogetherSoft и Borland, со-основатель сообщества тестировщиков Санкт-Петербурга

    Честно говоря, я с нетерпением ждал этого разговора. Во-первых, потому что мы долго работали вместе со многими ребятами из Oracle (еще когда мы работали на Sun). Вместе мы создавали с нуля тестовые сюиты, учились чему-то в тестировании, разрешали всякие интересные нетривиальные факапы и, конечно, постоянно попадали во всякие забавные ситуации. И могу точно сказать, что в питерском Oracle работают уникальные люди. Каждый раз заезжая к ребятам попить кофе, получаю массу удовольствия. :)

    Во-вторых, я знаю Лешу как драйвера (наряду с Ромой Твердохлебовым) питерского сообщества тестировщиков. И вижу как растет это сообщество – ребята просто молодцы!

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

    Причины, которые, как нам показалось, могут пояснить, почему 50% опрошенных, солидарны в своей позиции: «Тестировщики не понимают целей и задач тестирования».

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

    2. Мы не можем банально посчитать в цифрах эффективность наших решений и показать результаты нашей работы.

    3. Мы не готовы честно провести анализ полученных результатов и сказать «Да, я провтыкал и ошибся».

    4. Мы закапываемся в работу и забываем, что «пилу надо точить»: книги, вебинары, публикации, тренинги – всего этого в нашей отрасли сейчас навалом.

    5. Мы не смотрим шире своих рабочих задач: многие из нас тестировщиков «стажировались» в группе разработки за последний год? Не барское дело, понятно.

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

    Ко всему этому Слава Панкратов написал очень интересный пост со следующим выводом:

    Сейчас можно построить хорошую карьеру в тестировании ПО. Очень хорошую.

    От себя добавлю (говорит Капитан Очевидность): если сделать правильные выводы из предыдущих шести пунктов. :)

  • 34 минуты о командообразовании, которые вам надо посмотреть

    Posted on June 22nd, 2011 Александр Орлов 1 comment

    На конференции Стратоконф-1 Слава Панкратов сделал на бис свой доклад про роль мамонта в командообразовании – лучший доклад конференции Software People  2011 по отзывам слушателей. И в этот раз доклад был принят на ура – мамонт рулит. :)

    Официальное название доклада: “Командная аллергия и как ее избежать”. Обязателен к просмотру. :)

    P.S. Вот здесь доступны записи всех 8 отличных докладов конференции Стратоконф-1 и бесплатный пригласительный на Стратоконф-2. Требует регистрации.

  • Исследование успешности проектов: результаты

    Posted on January 10th, 2011 Александр Орлов No comments

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

    Андрей, проделавший масштабную работу по опросу участников и анализу результатов, в качестве подарка к наступившему 2011 году предложил опубликовать результаты исследования, что я и делаю. Результаты, однако, есть только на английском языке. Если найдутся добровольцы, желающие перевести, пишите на info@happy-pm.com !

    Что можно сказать о самом исследовании? Оно оказалось не таким масштабным как мы рассчитывали. Но для первого раза имхо достойно. (Для магистерской работы – просто супер. :) ) Всего было проанализировано 48 проектов.

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

    - 12% всех проектов не имели управления требованиями в принципе. Это означает, что в компании нет процесса управления разработкой ПО, или, говоря другими словами, процесс является хаосным.

    - Для 1/5 проектов требования предоставлялись заказчиком или другой организацией

    - 1/4 проектов имела детальные требования

    - 1 из 25 проектов имел специальные средства управления требованиями

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

    В общем, исследование получилось любопытным. Где-то результаты получились ожидаемыми, где-то не вполне. Но исследование хорошо уже тем, что оно было проведено. Андрею и всем, кто участвовал, большое спасибо и респект!

    Andrey Maglyas, EVALUATING THE SUCCESS OF SOFTWARE DEVELOPMENT PROJECTS IN RUSSIA, UKRAINE, AND BELARUS, pdf

  • Об этапах формирования команды

    Posted on December 8th, 2010 Александр Орлов No comments

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

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

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

    Слава Панкратов “Живые команды”

  • Как тестировщику повлиять на менеджера

    Posted on October 31st, 2010 Александр Орлов 2 comments

    Коллеги из software-testing.ru прислали цитату из статьи Майкла Болтона
    Тестировщики, хватит заниматься обеспечением качества. Как человек, много проработавший в тестировании, не могу не опубликовать, потому что Майкл, конечно, пишет дело:

    Рекомендации относительно того, как тестировщики могут оказывать позитивное влияние на менеджеров.

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

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

    - Полностью осознавайте, что они принимают не технические, а бизнес-решения.

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

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

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

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

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

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

    - Помогите менеджерам, а также программистам осознать, что автоматизация тестирования — это больше, гораздо больше, чем создание программы, которая заставляет компьютер нажимать на клавиши.

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

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

    - Помогите менеджерам и программистам избежать неверного понимания «фазы тестирования». На самом деле это: фаза обнаруженияи исправления ошибок.

    Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software и ведёт замечательный блог о тестировании www.developsense.com/blog.shtml

    17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.

  • Тяжело работать в опен спейсе! А начинать рабочий день еще тяжелее!

    Posted on July 19th, 2010 Александр Орлов 10 comments

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

    “Служебный роман” – вообще фильм про работу в офисе, как ни крути. Тут тебе и опен спейс, и поднятие визибилити, и интриги… :)

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


    Отличный, отличный фильм, надо его на тренингах показывать. :)

  • Человеческие проблемы ИТ менеджеров

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

    Спасибо Татьяне Гриценко, появилось видео моих комических куплетов на конференции DevPoint в Новосибирске. Вообще, надо заметить, что конференция удалась: много интересующегося народа, один поток, виски-брэйк, место для разговоров – все было отлично. Определенные накладки были (организаторы про них знают), но для первого раза это и не накладки совсем. Впечатление от первой ИТ конференции в Новосибирске строго положительные.

    Я там рассказывал для про человеческие проблемы ИТ менеджеров. Доклад рассчитан больше на тех, кто хочет стать менеджером или недавно им стал. Более опытные коллеги вероятно узнают себя какое-то время назад. :)

  • Вбок-вбок это хорошо, но вверх-вниз еще лучше

    Posted on May 7th, 2010 Александр Орлов 6 comments

    Влад Балин начал публикацию заметок по брошюре Ag;)e Checklist, которую Асхат Уразбаев с коллегами легкомысленно раздавали на конференции Software People. С интересом читаю эти заметки, потому то Влад пишет, как всегда, блестяще.

    А я свою брошюру вообще отдал кому-то на конференции, кому она была нужна позарез. Мне-то она не очень нужна, у меня есть книжка Асхата “Методичка по внедрению Scrum”, изданная тиражом 50 эксземпляров, с подписью автора.

    Но сейчас не об этом. В заметке о роли скрам мастера Влад приводит чудесный пример:

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

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

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

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

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

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

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

    И это замечательно. Пробуйте ротацию. Она творит чудеса.

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

    Причина №1. Непонятно, как это продать заказчику. Заказчик привыкает общаться с одним человеком, а тут ему что – каждую неделю к новому человеку привыкать. Более того, за проджект менеджера заказчик платит специальную ставку, а тут у него возникнет непонимание – за что он платит и кому. Учитывая, что в нашей отечественной индустрии доля заказной разработки высока, как там устраивать полноценную ротацию как в IBM – вообще непонятно.

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

    Но более распространенная причин, это конечно:

    Причина №2. Менеджмент про это как-то вообще не задумывается. :) Уходит менеджер в отпуск, на его место встает формальный заместитель. Единственная задача которого – заполнять собой графу “бэкап менеджера”. Заместитель собирает все задачи, которые накапливаются за две недели, с тем, чтобы вручить их свеже-отдохнувшему менеджеру.

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

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