• Опрос про веб-проекты – нужна ваща помощь

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

    Коллеги, срочно нужна ваша помощь – особенно тех, кто руководит/участвует в веб-проектах. Дело в том, что 8 октября в рамках конференции PHP Conf я выступлю с мастер-классом “10 мантр руководителя веб проектов”.

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

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

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

    В любом случае буду благодарен вам, если поделитесь своим опытом.

    1. (обязательно)
    2. (обязательно)
    3. (обязательно)
    4. (обязательно)
    5. (обязательно)
    6. (обязательно)
    7. (обязательно)
    8. (правильный e-mail)
     

    cforms contact form by delicious:days

    Uncategorized

  • Новый проект: RussianSoftware.org

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

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

    По этому поводу я решил сделать новый проект: RussianSoftware.org . Решил – и сделал. :)

    Проект будет посвящен популяризации опыта и лучших практик разработки софта в России, Украине, Беларуси, Эстонии, Казахстане и прилегающих странах. Проект расчитан на западную аудиторию, поэтому все материалы публикуются на английском языке.

    На сайте проекта будут появляться:

    • Новости отчетственного рынка разработки софта
    • Статьи о разработке софта (например, аналогия про такси)
    • Статьи о лучших практиках аутсорсинга
    • Интервью с владельцами и директорами отечественных компаний (первые три уже опубликованы)
    • Success stories об успешно выполненных проектах от менеджеров проектов
    • Профили городов СНГ и других стран exUSSR (конечно, первым освещен Питер :) )
    • …

    Если вы хотите принять участие (уговорить своего директора дать интервью, написать сакссесс стори своего проекта и пр., и пр.) – пишите на info@happy-pm.com . Вместе поднимем рынок отечественного софта! :)

    События

  • О пользе многоголовия

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

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

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

    Что делать? Откуда может родиться уважение сотрудников к такому начальнику? К начальнику, которыйперестает быть “практикующим врачом”.

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

    Не понимаешь (или не хочешь чего-то понимать в технических вещах) – оставь принятие технических решений самому грамотному техническому сотруднику. Умеешь лучше всех общаться с заказчиком – вот и общайся. И все.

    Да, появится определенное двухголовие – голова техническая и голова нетехническая. И иногда этим двум головам придется спорить между собой (сейчас делать рефакторинг, потому что “с архитектурой полная %опа” или подождать следующей итерации, когда заказчик продлит контракт). Но это меньшее из зол. И этот вариант вполне работает.

    В компании Intel эта практика одно время была даже закреплена на организационном уровне. У некоторых подразделений официально было два менеджера. Один отвечал за техническую сторону работы, второй – за бизнесовую. Ситуация называлась two-in-the-box. И работала вполне нормально. Пока не пришли консультанты и не сказали: “Что это за безобразие, не могут два начальника управлять одной командой!”  В итоге, каких-то менеджеров перевели в инженеры. То есть, де-юре они перестали быть менеджерами, но де факто все равно выполняли эту роль. Каких-то менеджеров сократили, в этом случае их роль стал играть кто-то другой. А куда деваться – надобность в роли никуда не исчезла.

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

    P.S. Да, я понимаю, что половина читателей сломала язык, выговаривая название этого поста. :)

    Менеджерские навыки

  • Интервью с командой PnP, Microsoft

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

    Аджой Кришнамурти, Григорий Мельник, Дон Смит

    На прошлой неделе, по пути со своего открытого тренинга, заскочил в офис Майкрософт, чтобы по просьбе Славы Панкратова выступить нештатным корреспондентом www.it4business.ru.

    Александр Орлов из московского офиса компании Microsoft.
    21 сентября шаттл бизнес-парка «Крылатские холмы» высадил меня на остановке самого бизнес-парка. Обычно я направлял свои стопы к зданию №4, где располагался офис Intel, но в этот раз прошел сквозь зеркальные двери здания №1. Прямо в офис Microsoft, где меня ждала беседа с ключевыми менеджерами команды MS Patterns & Practices (PnP) — по совместительству, главными докладчиками PnP Summit’а, который был назначен на следующий день. (Тут надо выразить отдельный респект команде CareerLab, которая все это организовывала. Ребята – молодцы, из раза в раз организовывают интересные мероприятия.)

    Завтра Аджой Криншамурти (Lead Product Planner), Григорий Мельник (Senior Program Manager) и Дон Смит(Program Manager) должны были выступать с докладами о продукте PnP и лучших практиках, которые они используют в команде, а сегодня они втроем сидели в конференц комнате и у меня было больше часа, чтобы расспросить их про все это в подробностях.

    Разговор оказался настолько интересным, что мы вышли за пределы часа. Но думаем, что вам будет интересно послушать то, о чем мы поговорили:

    • Что такое Patterns & Practices (PnP)?
    • Как PnP помогает разработчикам создавать бизнес-приложения
    • Интересные возможности, которые будут в MS visual Studio 2010
    • Agile практики, которые применяются внутри команды PnP
    • Трудности, с которыми столкнулись в команде PnP при внедрении Agile
    Аудио/Видео, Эксперты

  • IT-радио: Алексей Баранцев 30 сентября, 20:00 (МСК)

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

    Напоминаю всем, что 30 сентября в 20:00 (по московскому времени) состоится эфир IT-радио с Алексеем Баранцевым, главным редактором тестировочного портала software-testing.ru, постоянным организатором конференций SQA Days и т.д., и т.д.:

    30 сентября, 20:00 (МСК). Вопросы тестирования ПО. Гость: Алексей Баранцев, главный редактор портала www.software-testing.ru. Записаться на эфир!

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

    События

  • Цитата недели (Олег Тиньков)

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

    Я два слова знаю, которые в англо-саксонской транскрипции имеют положительный смысл, а в русской – негатив. Это “амбиции” и “миллионер”. Вот говорят: у него нездоровые амбиции. Что значит – нездоровые?! Они или есть, или нет.

    Цитаты

  • Расписание открытых тренингов Happy PM

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

    В 2010 году прошло 16 открытых тренингов Happy PM в 10 городах России, Украины и Беларуси. Суммарно их посетило порядка 320 человек.

    До конца 2010 года больше тренингов не планируется. Следующие тренинги планируются на февраль-март 2011 года в 10 городах:

    • Москва
    • Санкт-Петербург
    • Екатеринбург
    • Новосибирск
    • Киев
    • Харьков
    • Днепропетровск
    • Львов
    • Одесса
    • Минск

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

    Что такое открытые тренинги Happy PM? Это уникальные образовательные мероприятия для руководителей программных проектов и команд (и не только для них, о чем ниже). Без преувеличений, аналогов этим тренингам на пространстве бывшего СССР, не существует. Основные составляющие успеха:

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

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

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

    1. (обязательное поле)
    2. (обязательное поле)
    3. (обязательное поле)
    4. (правильный email)
    5. (обязательное поле)
    6. (обязательное поле)
    7. (обязательное поле)
     

    cforms contact form by delicious:days

    Read the rest of this entry »

    Мотивация сотрудников, События

  • Негласные истины управления ИТшниками

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

    Сегодня хочу привести ссылку на замечательную статью Джеффа Элло, которая в оригинале называется “Негласные истины управления гиками”. Я специально убрал слово “гики”, как нам не слишком близкое :) , и заменил его на слово ИТшники. К тому же, и в статье слово “ИТшник” употребляется гораздо чаще, нежели “гик”. Прекрасная статья, особенно интересен вывод. Про это на этой неделе появится пара постов. А вывод прямо-таки надо процитировать:

    Что делать

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

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

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

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

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

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

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

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

    Менеджерские навыки, Мотивация сотрудников

  • Семейство интересных методологий от Скотта Беркуна

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

    Как-то эта статья пролетела мимо меня полгода назад. И только недавно один из слушателей мне про нее рассказал. В общем, категорически интересное исследование Скотта Беркуна на тему методологий в ИТ. Практически, новое семейство методологий.

    Индустрия программного обеспечения — это, наверное, крупнейший в мире питомник новых систем управления. Agile, Экстремальное Программирование, Разработка Через Тестирование (Test Driven Development, TDD) — акронимы и фреймворки продолжают плодиться. Почему?

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

    (Позитивный список, я уверен, существует, но вот вам циничный)

    Разработка через задницу (Asshole Driven Development, ADD) — любая команда, в которой наибольший придурок принимает все важные решения, занимается разработкой через задницу. Здравый смысл, логика и процесс вышвыриваются в окно, когда мистер Задница находится в комнате и делает то, что считает нужным, каким-бы глупым и эгоцентричным это ни было. Правила и процессы могут присутствовать, но м-р З. нарушает их и люди все равно следуют ему.

    Разработка через когнитивный диссонанс (Cognitive Dissonance development, CDD) — происходит в любой организации, где существует две и более различных точки зрения на то, как нужно писать программы. Напряжение между этими точками зрения, будучи проявлено в различных митингах и индивидуальных решениях участниками по обеим сторонам баррикад, определяет проект в большей степени, чем каждая из точек зрений в отдельности.

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

    Разработка через отрицание (Development By Denial, DBD) — все притворяются, что существует метода, для того, что происходит, и что все в порядке, тогда как на самом деле все в полном беспорядке, а процесс пылится в углу. Чем хуже идут дела, тем более выживание зависит от отрицания того, что происходит на самом деле, или от изоляции в своей маленькой части проекта.

    Методология «Повысьте меня» (Get Me Promoted Methodology, GMPM) — Люди пишут код и решают задачи так, чтобы увеличить свою видимость, удовлетворить прихоти своего босса и ускорить свой путь к повышению или просторному кабинету, при этом не важно насколько далеки их усилия от поставленных целей. Среди прочего, допускаются аварийные ситуации, для того чтобы выглядеть героем, создавая заплатки, которые выглядят великолепно в краткосрочной перспективе, однако рассыпаются в прах, как только человек двинулся дальше; фокус сосредоточен на поверхности работы, а не на ее значении.

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

    Fun

  • Запись тренинга “Машина проекта” – в продаже

    Posted on September 26th, 2009 Александр Орлов No comments
    Недавно получили отзыв от слушательницы нашего со Славой тренинга “Машина проекта”: http://kstref74.livejournal.com/9889.html и решили таки выставить запись тренинга в продажу.

    Вообще, должен сказать, что испытываю определенную гордость за этот тренинг, потому что такого количества практических инструментов мы со Славой еще никогда не давали. И неизвестно, когда еще будем давать. :) Надеюсь, участники “Машины проекта” таки внедрили их использование в жизнь.

    В общем, если кто-то считает, что ему это нужно, то вы можете приобрести запись тренинга (слайды + аудио + практические инструменты),  заполнив форму на странице “Машины проекта”. Стоимость: 5000 рублей.

    События
  • « Older Entries