Коллеги, срочно нужна ваша помощь – особенно тех, кто руководит/участвует в веб-проектах. Дело в том, что 8 октября в рамках конференции PHP Conf я выступлю с мастер-классом “10 мантр руководителя веб проектов”.
К мастер-классу я хотел бы присовокупить небольшое исследование успешности-провальности веб-проектов. У меня есть некоторые данные, но хотелось бы их дополнить. Собственно, для этого и сооружен небольшой опрос, который приведен ниже.
Если вы можете/хотите поделиться про несколько веб-проектов, в которых вам довелось принимать участие – буду благодарен вдвойне и втройне.
Опрос строго конфиденциальный. Последним полем указан e-mail – это означает что я, может быть, задам несколько уточняющих вопросов. А может быть, и не задам.
В любом случае буду благодарен вам, если поделитесь своим опытом.
Как известно, я много общаюсь с людьми. На конференциях, на тренингах. По моим наблюдениям, многие (особенно директора компаний) пребывают в некотором унынии по поводу того, что клиентов стало мало. Кризис там и все такое…
По этому поводу я решил сделать новый проект: RussianSoftware.org . Решил – и сделал.
Проект будет посвящен популяризации опыта и лучших практик разработки софта в России, Украине, Беларуси, Эстонии, Казахстане и прилегающих странах. Проект расчитан на западную аудиторию, поэтому все материалы публикуются на английском языке.
На сайте проекта будут появляться:
Если вы хотите принять участие (уговорить своего директора дать интервью, написать сакссесс стори своего проекта и пр., и пр.) – пишите на info@happy-pm.com . Вместе поднимем рынок отечественного софта!
Когда я прочел статью Джэффа Элло про управление гиками, то в моей голове сразу же возник вопрос, что делать тем менеджерам, которые так или иначе утратили технические навыки?
Действительно, такое происходит достаточно часто. Иногда по историческим причинам. Иногда по организационным причинам – на менеджера наваливают кучу доселе неведаных обязанностей. Иногда технических навыков происходит и по инициативе самого менеджера, который наконец (!) перестает ломать мозги над техническими проблемами и уходит в “область человеческих отношений”. Иногда, как в случае с девочкой Олей, менеджером назначают человека с наилучшими коммуникативными навыками. При этом понятно, что технических навыков у такого менеджера меньше, чем у его подчиненных.
Что делать? Откуда может родиться уважение сотрудников к такому начальнику? К начальнику, которыйперестает быть “практикующим врачом”.
Имхо, тут все достаточно просто. Каждый должен делать то, что он умеет лучше всего. И не лезть своими управленческими руками туда, где он умеет хуже. Недоверие и неуважение со стороны инженеров рождается, когда менеджер пытается принимать решения в той области, где он, условно говоря, понимает хуже.
Не понимаешь (или не хочешь чего-то понимать в технических вещах) – оставь принятие технических решений самому грамотному техническому сотруднику. Умеешь лучше всех общаться с заказчиком – вот и общайся. И все.
Да, появится определенное двухголовие – голова техническая и голова нетехническая. И иногда этим двум головам придется спорить между собой (сейчас делать рефакторинг, потому что “с архитектурой полная %опа” или подождать следующей итерации, когда заказчик продлит контракт). Но это меньшее из зол. И этот вариант вполне работает.
В компании Intel эта практика одно время была даже закреплена на организационном уровне. У некоторых подразделений официально было два менеджера. Один отвечал за техническую сторону работы, второй – за бизнесовую. Ситуация называлась two-in-the-box. И работала вполне нормально. Пока не пришли консультанты и не сказали: “Что это за безобразие, не могут два начальника управлять одной командой!” В итоге, каких-то менеджеров перевели в инженеры. То есть, де-юре они перестали быть менеджерами, но де факто все равно выполняли эту роль. Каких-то менеджеров сократили, в этом случае их роль стал играть кто-то другой. А куда деваться – надобность в роли никуда не исчезла.
Подводя итог. Менеджерам, которые не владеют технической стороной вопроса, не стоит лезть в технику и пытаться принимать технические решения. Это верный способ полностью растерять уважение команды. Приобрести уважение можно, только делая то, что ты умеешь делать лучше всех.
P.S. Да, я понимаю, что половина читателей сломала язык, выговаривая название этого поста.
Аджой Кришнамурти, Григорий Мельник, Дон Смит
На прошлой неделе, по пути со своего открытого тренинга, заскочил в офис Майкрософт, чтобы по просьбе Славы Панкратова выступить нештатным корреспондентом 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 и лучших практиках, которые они используют в команде, а сегодня они втроем сидели в конференц комнате и у меня было больше часа, чтобы расспросить их про все это в подробностях.
Разговор оказался настолько интересным, что мы вышли за пределы часа. Но думаем, что вам будет интересно послушать то, о чем мы поговорили:
Напоминаю всем, что 30 сентября в 20:00 (по московскому времени) состоится эфир IT-радио с Алексеем Баранцевым, главным редактором тестировочного портала software-testing.ru, постоянным организатором конференций SQA Days и т.д., и т.д.:
30 сентября, 20:00 (МСК). Вопросы тестирования ПО. Гость: Алексей Баранцев, главный редактор портала www.software-testing.ru. Записаться на эфир!
Какие-то вопросы к Алексею у меня уже собраны. Но если вы хотите чтобы ваш вопрос наверняка прозвучал в эфире, пожалуйста, задавайте его комментариями к этому посту.
Я два слова знаю, которые в англо-саксонской транскрипции имеют положительный смысл, а в русской – негатив. Это “амбиции” и “миллионер”. Вот говорят: у него нездоровые амбиции. Что значит – нездоровые?! Они или есть, или нет.
В 2010 году прошло 16 открытых тренингов Happy PM в 10 городах России, Украины и Беларуси. Суммарно их посетило порядка 320 человек.
До конца 2010 года больше тренингов не планируется. Следующие тренинги планируются на февраль-март 2011 года в 10 городах:
Если вам было бы интересно принять участие в каком-то из этих тренингов, записывайтесь в форму ниже. Вы первым получите письмо о тренинге в вашем городе, когда расписание будет утверждено.
Что такое открытые тренинги Happy PM? Это уникальные образовательные мероприятия для руководителей программных проектов и команд (и не только для них, о чем ниже). Без преувеличений, аналогов этим тренингам на пространстве бывшего СССР, не существует. Основные составляющие успеха:
Ниже – подробно о каждом пункте, информация о ведущем и тех, кто уже прошел обучение, а также о стоимости тренингов. Также вы можете ознакомиться с отзывами участников.
Если вы хотите поучаствовать в каком-либо тренинге, пожалуйста, оставьте свою заявку заранее. Как показывает опыт, мест на всех может не хватить.
Сегодня хочу привести ссылку на замечательную статью Джеффа Элло, которая в оригинале называется “Негласные истины управления гиками”. Я специально убрал слово “гики”, как нам не слишком близкое
, и заменил его на слово ИТшники. К тому же, и в статье слово “ИТшник” употребляется гораздо чаще, нежели “гик”. Прекрасная статья, особенно интересен вывод. Про это на этой неделе появится пара постов. А вывод прямо-таки надо процитировать:
Что делать
Поэтому, если вы хотите получить действительно довольную, здоровую и ценную ИТ-группу, я могу порекомендовать только одно: проявляйте интерес. Айтишники будут работать до потери пульса для людей, которых они уважают, поэтому вы должны дать им для этого все причины.
Начать можно еще в процессе найма. Нанимая айтишника, представьте, что нанимаете доктора. А нанимая руководителя отдела ИТ, подумайте о найме главврача. У главврача должно быть несколько квалификаций, но первое и самое главное — он должен быть практикующим врачом. Кто решает, является ли врач врачом? Другие врачи! Так что если ваша ИТ-группа не присутствует за столом при найме своих начальников или коллег, то это уже наносит вред всему процессу.
Отдавайте предпочтение технической компетенции и лидерским навыкам. Стандартные управленческие процессы практически бесполезны в ИТ-группе. Как говорилось ранее, если вы удачно наняли рядовых членов группы, то они уже знают, как управлять процессом. В отличие от многих отраслей, в большинстве ИТ-групп борьба идет не за то, как избежать работы, а за то, как выполнить задачу. Ради выполнения задачи айтишники могут сами себя организовать, дезорганизовать и перевернуть с ног на голову. Замысловатый, технически слабый коротышка, занимающийся микро-менеджментом, каким бы отполированным он не был, заброшенный в этот котел только для управления, получит от профессиональной ИТ-группы такую же реакцию, какую получит пятилетний ребенок от взрослого, которого он дергает за штанину.
Айтишникам нужен менеджер, который выслушает и даст общее направление. Лидерские качества и техническая компетентность должны присутствовать у каждого члена команды. Если вам нужен человек, который будет отслеживать ход проектов, составлять отчеты и работать с заказчиками, вы можете за гораздо меньшую зарплату нанять ассистентов.
Что касается проверок продуктивности, годовые обзоры бессмысленны без всесторонней (или 360-градусной) оценки. Такие вещи требуют больше времени, чем простой нисходящий обзор, но это время будет потрачено с пользой. Если вы внимательно прочли все, что я писал о поведении и организации ИТ-групп, то вы сможете посмотреть на свою ИТ-группу в ином свете, когда будете читать результаты ее всесторонней оценки.
И убедитесь, что все ваши менеджеры являются практикующими и обучаемыми. На таких должностях очень легко скользить по кривой, но, как и с врачами, практика и поддержка навыков — это единственный способ оставаться компетентным. В ИТ уважение и некомпетентность разделяются лишь сроком от шести месяцев до года.
И наконец, у руководителей в распоряжении должно быть несколько путей подхода к ИТ-команде. Если команда начинает фальшивить, то стоит разобраться и выяснить причины. Но вы никогда даже не узнаете, что такое происходит, если вашим единственным источником информации будет руководитель отдела ИТ. Периодически приглашайте ключевых айтишников на совещания, чтобы они могли понаблюдать за общими проблемами организации, даже если речь идет о вещах, не относящихся к миру ИТ, хотя бы для того, чтобы воспользоваться их высокочувствительными датчиками бреда. Хороший айтишник обучен выполнять поставленные задачи, и его навыки не обязательно ограничиваются только компьютерами. Кстати, из всех, кого я знаю, лучшие деловые решения принимают именно айтишники, при этом, даже не являясь менеджерами.
Как я говорил в самом начале, все дело в уважении. Если вам удастся выявить и поддержать тех людей и те процессы, которые приносят подлинное уважение айтишников, у вас будет великолепная ИТ-команда. Неподдельная заинтересованность в том, чтобы помочь айтишникам помочь вам — вот, пожалуй, самый умный ход для организации. Так вы получите довольных, абсолютно негиковых гиков.
Как-то эта статья пролетела мимо меня полгода назад. И только недавно один из слушателей мне про нее рассказал. В общем, категорически интересное исследование Скотта Беркуна на тему методологий в ИТ. Практически, новое семейство методологий.
Индустрия программного обеспечения — это, наверное, крупнейший в мире питомник новых систем управления. Agile, Экстремальное Программирование, Разработка Через Тестирование (Test Driven Development, TDD) — акронимы и фреймворки продолжают плодиться. Почему?
Кто-то скажет: незрелость — производство ПО еще молодая промышленность и все эти изменения — путь к некоторым истинным основам. Другие говорят, это потому, что люди от программирования просто любят выдумывать всякие штуки и сами не могут разобраться. А я скажу так: раз уж мы идем к тому, чтобы иметь дюжины моделей, хотя бы некоторые из них могут быть честными, хотя и циничными, по отношению к тому, что на самом деле происходит большую часть времени.
(Позитивный список, я уверен, существует, но вот вам циничный)Разработка через задницу (Asshole Driven Development, ADD) — любая команда, в которой наибольший придурок принимает все важные решения, занимается разработкой через задницу. Здравый смысл, логика и процесс вышвыриваются в окно, когда мистер Задница находится в комнате и делает то, что считает нужным, каким-бы глупым и эгоцентричным это ни было. Правила и процессы могут присутствовать, но м-р З. нарушает их и люди все равно следуют ему.
Разработка через когнитивный диссонанс (Cognitive Dissonance development, CDD) — происходит в любой организации, где существует две и более различных точки зрения на то, как нужно писать программы. Напряжение между этими точками зрения, будучи проявлено в различных митингах и индивидуальных решениях участниками по обеим сторонам баррикад, определяет проект в большей степени, чем каждая из точек зрений в отдельности.
Методика «Прикрой свою задницу» — двигателем большинства личных усилий является желание не попасть под удар, когда запахнет жареным.
Разработка через отрицание (Development By Denial, DBD) — все притворяются, что существует метода, для того, что происходит, и что все в порядке, тогда как на самом деле все в полном беспорядке, а процесс пылится в углу. Чем хуже идут дела, тем более выживание зависит от отрицания того, что происходит на самом деле, или от изоляции в своей маленькой части проекта.
Методология «Повысьте меня» (Get Me Promoted Methodology, GMPM) — Люди пишут код и решают задачи так, чтобы увеличить свою видимость, удовлетворить прихоти своего босса и ускорить свой путь к повышению или просторному кабинету, при этом не важно насколько далеки их усилия от поставленных целей. Среди прочего, допускаются аварийные ситуации, для того чтобы выглядеть героем, создавая заплатки, которые выглядят великолепно в краткосрочной перспективе, однако рассыпаются в прах, как только человек двинулся дальше; фокус сосредоточен на поверхности работы, а не на ее значении.
Взято отсюда. Если же заглянуть на страницу оригинала (на английском), то в комментариях можно обнаружить еще немало интереснейших методологий и подходов.
Вообще, должен сказать, что испытываю определенную гордость за этот тренинг, потому что такого количества практических инструментов мы со Славой еще никогда не давали. И неизвестно, когда еще будем давать. Надеюсь, участники “Машины проекта” таки внедрили их использование в жизнь.
В общем, если кто-то считает, что ему это нужно, то вы можете приобрести запись тренинга (слайды + аудио + практические инструменты), заполнив форму на странице “Машины проекта”. Стоимость: 5000 рублей.
Последние коментарии