• Цитата недели (Акио Морита)

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

    Люди работают не только ради денег, и если вы пытаетесь мотивировать людей, деньги не самый эффективный инструмент.

  • Тупые пользователи – вот кто проваливает проекты!

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

    Слушательница нашего новосибирского тренинга Анна Сартакова опубликовала любопытный обзор исследований успешности проектов. В очередной раз увидел статистику от Standish Gorup и снова порадовался:

    Результат завершения проекта 1995 2002 2004 2006 2008
    Завершены успешно 16% 34% 29% 35% 32%
    Вышли за рамки запланированного бюджета, сроков, либо не достигли цели 53% 51% 53% 46% 44%
    Потерпели неудачу 31% 15% 19% 19% 24%

    Что еще пишут исследователи:

    Исследователи также пишут, что были названы и такие забавные причины как “brain-dead users, only brain-dead users” (тупые пользователи, это всё тупые пользователи!).

    Однозначно! Тупые пользователи – с ними ничего нельзя поделать!

    Ну и напоследок товарищ Роберт Голдсмит, конечно, сказал правду:

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

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

    Для тех читателей, в чьей стране Живой Журнал не работает, приводим статью полностью здесь.

    Read the rest of this entry »

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

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

    Стало доступно видео выступления Макса Дорофеева на совместном семинаре MO PMI и Гильдии менеджеров программных проектов.

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

  • Кейс “Неукротимая Маша”

    Posted on March 12th, 2010 Александр Орлов 54 comments

    Один из читателей прислал вопрос, который было решено сделать кейсом.

    Кейс “Неукротимая Маша”

    Дело было так. Была в моей группе девушка, программистка. И вот я говорю ей: “Маша, надо сделать вот такую функцию, и сделать ее надо вот таким образом, потому что так будет удобно нашему заказчику”. На что Маша мне отвечает: “Делать как ты сказал я не буду, потому что мне так не нравится. И вообще, ты для меня не авторитет”.

    Не то чтобы Маша не хотела работать, нет, она вполне трудолюбивая и грамотная. Просто характер у нее… вредноватый. Обсудить с ней проблему можно, но она останется при своем мнении – “не буду делать”. А может еще и личная неприязнь какая присутствует.

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

    И все, затык. Как строить дальнейший диалог – совершенно непонятно. А работу делать надо, деваться некуда.

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

    Мотивировать, бегать вокруг такого сотрудника – честно говоря, никакого желания нет. К слову, “уговаривать” – это был единственный способ заставлять Машу делать как нужно, а не как ей хочется.

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

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

    А как бы Вы поступили? Как эффективно реагировать на выпендреж в духе “ты мне не авторитет и не указ”?

  • Гости на украинских тренингах Happy PM

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

    Поддерживается традиция приглашения интересных гостей на открытые тренинги Happy PM.

    14 марта в Киеве на дне, посвященном карьере менеджера, выступит Слава Панкратов, директор учебного центра Люксофт Украина, основатель ряда интернет порталов, включая www.software-testing.ru и www.it4business.ru , человек, открывавший офис по разработке компании Яндекс в Киеве. Слава поделится своими мыслями о карьерном пути менеджера.

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

  • Питерские тестировщики готовятся к приезду Алексея Баранцева

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

    Все питерские тестировщики замерли в ожидании – в город трех революций собирается сам Алексей Баранцев!

    Энциклопедическая справка: Алексей Баранцев, главный редактор портала www.software-testing.ru, автор и ведущий многочисленных курсов по тестированию ПО, постоянный организатор конференций SQA Days, руководитель отдела коммерческих разработок Института Системного Программирования РАН. По последним измерениям обладает одним из самых широких кругозоров в области техник, методик и инструментов тестирования ПО.

    Алексей будет в Питере 1-3 апреля с тремя очными тренингами:

    Спешите записываться сами и записывать туда своих коллег-тестировщиков. Мест может не хватить.

  • Лучшие менеджеры – из тестеров или из программистов?

    Posted on March 11th, 2010 Александр Орлов 2 comments

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

    Довольно часто спрашивают (особенно, почему-то директора :) ), из кого получаются лучшие менеджеры – из программистов или из тестировщиков?

    Если посмотреть на статистику, то по факту:

    • 44% менеджеров пришли из программистов
    • 19% пришли из тестировщиков
    • 14% пришли из аналитиков
    • 6% пришли из не технических специалистов
    • 4% пришли из архитекторов

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

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

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

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

    У тестировщиков, которые становятся менеджерами, с этим попроще. Они изначально кодируют хуже, чем многие разработчики в проекте. Поэтому делегирование – единственный путь вообще что-либо сделать. Но у менеджеров-экс-тестировщиков возникает другая проблема – с авторитетом. “Как это так – ничего не понимает в коде, а стал менеджером?” – этим вопросом будет задаваться половина разработчиков в проекте. Авторитет придется завоевывать. А это уже во многом психология, а не написание тест планов.

    А что там с предрасположенностями? Тоже все понятно. Программист лучше всех знает код ядра проекта, лучше всех умеет программировать, и даже, вероятно, знает больше всех паттернов из незабвенной книжки “Паттерны проектирования”. Соответственно, технические решения принимаются относительно легко.

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

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

  • Культуры программных проектов: глава 7

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

    Культуры программных проектов

    Автор: Энтони Лаудер

    Перевод: Альберт Мустафин

    Глава 7: Корпоративная Культура

    Столкновения Культур

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

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

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

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

    Навязывание команде методологии, которая отражает другое мировоззрение, создаст конфликт по всем направлениям, и, разумеется, столкнётся с заметным сопротивлением.

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

    Сконструированный Мысленный Образ

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

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

    На одной презентации выступающий сказал, что “гибкая разработка приложений (agile software development) включает в себя координирование действий разработчиков так, чтобы завершить пункты из списка требований к продукту, которые были приоритезированы в терминах того, как заказчик обозначил их важность”. Так продолжалось некоторое время, и я явно заметил в аудитории несколько человек, потерявших интерес. Слишком много было слов, слишком уныло. Куда лучше было бы со слайдом из трёх слов, но с более действенным мысленным образом: “непрерывное удовлетворение заказчика”, с паузой после него, чтобы аудитория подумала о смысловых интерпретациях самостоятельно, прежде чем докладчик продолжит.

    Сильные мысленные образы очень важны для быстрой и действенной работы метафор.

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

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

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

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

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

    Изменение Культур

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

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

  • Невозвращенный долг: разбор кейса

    Posted on March 9th, 2010 Александр Орлов 3 comments

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

    Вначале о наболевшем. :)

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

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

    Наболевшее №3. Не надо такие проблемы решать по почте. Судя по всему, тут срочный вопрос, который людей волнует. Тут надо минимум звонить, максимум ехать в Харьков. Звоните.

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

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

    Сообщите возможность выделения 4 человек сроком на 3 недели.

    Не производится нападок вроде “Однако этого до сих пор не произошло” как в 1-м варианте. И не высказывается сразу же давящая позиция: “В противном случае мы будем вынуждены отозвать наших сотрудников, занятых на проекте Х”, как во 2-м варианте.

    Обрисовывается ситуация.Показывается желание слушать собеседника. Отличный партнерский вариант.

    Если же отношения между Киевом и Харьковом натянутые и задача киевского офиса продавить харьковчан, то тогда можно сразу посылать 2-й вариант:

    В соответствии с договоренностью с руководителем направления N Андреем К. сотрудники нашего филиала выполняют часть работ по вашему проекту Х в объеме 12 человеко-месяцев. Но до сих пор в наше распоряжение не поступили сотрудники вашего филиала, что также входило в договоренность с Андреем.

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

    Потом можно отключить почту и телефон и свалить на харьковчан то, что они поздно засуетились.

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

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

  • Цитата недели (Игорь Ашманов)

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

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