• Почему жизнь – не сказка?

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

    Хотел написать сразу по мотивам минских SQA Days 2008, но забыл. Потому что забыл записать. :) Теперь исправляюсь.

    Во всех детских сказках, когда спрашивают главного героя – куда ты, Ваня, едешь? – он отвечает что?

    - Еду туда-то, туда-то, людей посмотреть и себя показать.

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

    А в реальной жизни что? Почему-то большинство посетителей конференций ездит только людей посмотреть. Иначе чем еще можно объяснить то, что у половины людей нет с собой визиток? Чем еще можно объяснить то, что информацию из людей надо тянуть клещами? А уж такого, чтобы человек с горящими глазами что-то рассказывал про свою компанию – такое вообще, по-моему, только у докладчиков видел. И еще у пары людей. Есть острое ощущение, что всем остальным нужно прописать сказкотерапию. :)

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

    А поскольку визитка – хороший, проверенный временем инструмент, то домашнее задание для тех, кто еще не:

    • Заведите себе визитки. Если на работе не делают, сделайте их себе сами (100 визиток обойдутся вам в ~300 рублей).
    • Выработайте рефлекс вместе с фразой “Давайте познакомимся” раздавать всем вокруг свои визитки
    • Таки выработайте elevator pitch – то бишь небольшой рассказ о себе и своей работе/хобби. Чтобы не мычать, в случае когда вас спросят, чем же вы занимаетесь.

    И жизнь превратится в сказку? Возможно. По крайней мере, станет интересней. :)

    P.S. Несколько полезных статей на ту же тему от Алекса Левитаса, гуру партизанского маркетинга:

    http://www.levitas.ru/BD/bd95.htm

    http://www.levitas.ru/BD/bd53.htm

    http://www.levitas.ru/BD/bd54.htm

    Там многое нужно не менеджеру программистов, а предпринимателю, но еще большее пригодится и менеджеру тоже. :)

    P.P.S. Еще одна хорошая статья про то, как сделать визитку говорящей, от неизвестного мне автора:

    http://tavly.blogspot.com/2007/09/1100.html

    Например, можно написать на ней “ненавижу тех, кто ненавидит виндовз”. :)

  • Интервью с Алексеем Дмитриевым, Motorola

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

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

    В общем, были покрыты следующие темы:

    • История преобразования ковыляющего проекта в летящий
    • Различия в понимании вещей на разных уровнях
    • Главное качество проджект менеджера
    • Когда менеджер становится полностью готов перейти наверх
    • Вреден ли перфекционизм в оценке людей
    • Три фактора мотивации сотрудников
    • Кто такой “хороший начальник”
    • Близость к пользователю – еще один фактор мотивации

    Текст интервью в pdf

  • Последнее место на Happy PM Reality Show: кто быстрее?

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

    Внезапно освободилось одно место (не смогла приехать участница из Харькова) на открытый тренинг Happy PM, который пройдет в Питере 12-15 декабря. В связи с этим объявляется конкурс “кто быстрее”. :) Первый, кто впишется на это место, сможет попасть на тренинг за 10000 рублей, то есть меньше, чем за первоначальную цену.

    Также определились детали мероприятия:

    Действо пройдет в офисе компании Sun Microsystems в С-Петербурге. На тренинг сейчас записано 20 человек. Компания интересная – из Питера, Москвы, Днепропетровска, Пскова, Новгорода.

    В основном, на тренинге будем жечь мы с Игорем Одинцовым, но будут также приглашенные спикеры.

    На секции “Управление командой”:

    На секции “развитие карьеры”:

    • Григорий Лабзовский, директор С-Петербургского филиала Sun Microsystems
    • Алексей Дмитриев, операционный менеджер WiMAX, Motorola
    • Еще один питерский ИТ топ-менеджер, имя которого держится в секрете :)

    Все участники действа получат футболки и фирменную символику проекта Happy PM, а также полный пакет аудиозаписей проекта Happy PM (включая аудио системы стоимостью $257).

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

    Итого: объявляется одна свободная позиция за 10000 рублей, которую можно занять, если быстро напишите мне на info@happy-pm.com и окажетесь первым.

  • Цитата недели (Говард Шульц)

    Posted on December 9th, 2008 Александр Орлов 2 comments

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

  • Борцы с бизнесом

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

    HPM Reality Show: открытый тренинг проекта Happy PM, 12-15 декабря 2008, С-Петербург

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

    - С каким кодом? – переспросил кто-то.

    - Ну, с говнокодом – нашелся рядом другой специалист.

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

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

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

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

    Меня это неизменно поражало. Казалось бы, это очевидно – бизнес есть бизнес. Раньше вышел – зарабатываешь деньги. Позже вышел – кто-то уже зарабатывает деньги вместо тебя. Но “борцы за качество” борются за качество, а не за деньги. :)

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

    Но в этот раз приходит “борец за качество”. Он сидит час, второй. Ты робко заглядываешь: мол, как там, не близится ли конец работ?

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

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

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

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

    P.S. Коллега oldjackaroo кинул старую ссылку, которую я, однако, не видел – про русского, китайского, индусского и канадского программистов. Очень жизненно. :)

  • Sunday Fun: Every Build You Break…

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

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

    Fun
  • ИТ-такси

    Posted on December 5th, 2008 Александр Орлов 21 comments

    HPM Reality Show: открытый тренинг проекта Happy PM, 12-15 декабря 2008, С-Петербург

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

    Fixed price. Вот, например, что такое fixed-price проект? Это когда тебе нужно добраться с юго-запада в центр, а в кармане 200 рублей. Метро закрылось, маршрутки спят. Выходишь на дорогу с протянутой рукой. Останавливаются машина:

    - До центра довезете?

    - До центира куда?

    - До Исакия.

    - Сикока?

    - 100 рублей.

    - Нафик.

    И так по циклу. Пока не найдется какой-нибудь “фрилансер”, который довезет. Если сумма побольше, то ловить придется совсем недолго.

    То есть fixed-price – это когда ты точно знаешь, куда тебе надо. А денег хочешь потратить вот ровно столько.

    Почему пассажиры любят fixed price? Потому что точно знаешь, сколько потратишь. И водитель мотивирован довезти тебя максимально быстро. Чтобы поехать дальше бомбить. И это одновременно означает снижение качества поездки – комфорта и безопасности.

    А что такое Time & Materials? Это, конечно, такси со счетчиком. 15 рублей за километр. Вроде не так и много. В 200 рублей должен уложиться. Садишься. Но потом замечаешь, что почему-то счетчик щелкает, когда машина стоит. А водитель тебя везет как-то подозрительно долго. И в итоге – опа-на, 450 рублей.

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

    А когда надо выбирать T&M? Очевидно тогда, когда ты знаешь оптимальную дорогу, чтобы контролировать, как тебя везут. Ну и когда предположительная цена по счетчику меньше той, что таксист хочет в качестве fixed price. Как-то так.

    А вот Agile сюда приделать никак не получается. Не получится на такси ездить короткими итерациями. :) Поэтому модель ИТ-такси нельзя назвать всеобъемлющей. А так очень похоже. Компании – это такси. Фрилансеры – это бомбилы. Фулл-тайм программист в аутсорсе – личный шофер. :)

  • Weborub – анти-отчет

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

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

    Вместо этого там предполагалось живое общение в закрытом кругу участников. Которых организаторы тщательно отбирают. Чтобы мышь не проскользнула.

    Когда Саша меня туда позвал, я насторожился. Там ведь наверняка будет много веб-разработчиков. Вдруг, кто видел мой старый сайт?! Сделанный на коленке при помощи моих зачаточных знаний про HTML и мега-инструмента SeaMonkey Composer. Ехать было опасно. Но я рискнул. И не прогадал, о чем ниже.

    Спойлер: дальше про фетиши в управлении проектами, красные бусы и игры со странными названиями. :-)

    Read the rest of this entry »

  • О силе простотака

    Posted on December 3rd, 2008 Александр Орлов 10 comments

    HPM Reality Show: открытый тренинг проекта Happy PM, 12-15 декабря 2008, С-Петербург

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

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

    Проходит какое-то время. Люди тоже начинают делать какие-то вещи – пишут книги, или там сайты свои делают. Приходят к моему товарищу. Говорят: “Вася, давай ты про меня расскажешь?” Вася говорит: “Да, конечно. Несколько тысяч рублей – и вы станете нашим спонсором. Мы работаем только так. Правда, мы в спонсоры берем только солидные компании…”

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

    Эту историю я наблюдал неоднократно, когда еще не делал проект Happy PM. А тут Вася обратился ко мне с просьбой: “Саша, давай ты про меня расскажешь”, и я решил проверить, не поменялась ли случайно маркетинговая схема. Не поменялась. Все так же в одну сторону. :)

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

    QA менеджер думает, и, допустим, соглашается. При этом, конечно, идет на некоторый риск. Но релиз спасен, все счастливы.

    Через какое-то время случается обратная ситуация – и QA менеджер приходит к менеджеру команды разработчиков и предлагает то же самое. Тот мнется, жмется, прячет глаза и говорит: “Знаешь, давай лучше не будем. Мало ли что.” QA менеджер растерянно уходит. Релиз проваливается, ему влетает. Отношения между менеджерами портятся навсегда.

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

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

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

    Многие спрашивают: Саша, а как выстроить отношения с коллегами, когда ты прихожишь в новый проект/команду/компанию? Есть очень простой способ, который проверен неоднократно.

    Сделайте для них что-нибудь хорошее просто так.

    Спрашивает на митинге менеджер: у нас есть вот такая задача, но не хватает ресурсов. Кто может помочь? Все молчат – кому нужна лишняя работа?.. Это ваш выход – берите и делайте.

    Услышали или прочитали что-то, что может помочь коллегам – это ваш выход. Оторвите задницу от стула, пойдите и расскажите им. Даже если у вас все горит, и времени нет.

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

    Примерно так.

    P.S. Приношу свои извинения тем, кто, прочтя заголовок поста, подумал, что  речь пойдет о рекламе лекарств. Хотя боюсь, что вы до этого места не дочитали. :)

  • AgileDays – 12 декабря, Москва

    Posted on December 2nd, 2008 Александр Орлов 3 comments

    Коллеги из дружественного гибкого киберпространства сообщили об интересном событии, которое будет иметь место 12 декабря в Москве – AgileDays. Событие интересно, во-первых, тем, что оно бесплатно :) , а во-вторых, тем, что на него приезжает Майкл Физерс (Michael Feathers) – заслуженный человек, гуру гибких методологий.

    У события есть один существенный минус – оно по времени накладывается на открытый тренинг проекта Happy PM. :) Но если на открытый тренинг вы пойти не смогли, и если вы работаете в Москве, то нужно срочно послать своих инженеров на AgileDays :) , чтобы люди почувствовали себя в индустрии, пообщались с коллегами и вернулись с горящими глазами и морем идей, как надо выстроить свою жизнь, чтобы оно стало лучше.

    Программа конференции довольно любопытная:

    Michael Feathers – Working Effectively with Legacy Code (эффективная работа с унаследованным кодом)

    This talk presents a collection of dependency breaking and test writing techniques that can be used to get existing code safely under test for refactoring and enhancement. These techniques can be used in conjunction with Test Driven Development to breathe new life into large existing code bases.

    (доклад Майкла не будет сопровождаться переводом)

    Алексей Баранцев – Каким должно быть приёмочное тестирование в agile-проектах?
    (ИСП РАН, аккаунт-менеджер; главный редактор проекта Software-Testing.Ru)

    Буквально каждая книжка, посвящённая agile-методам разработки подробно рассказывает о том, как и зачем использовать unit-тестирование. Интернет также полон статей, заметок, обсуждений, посвящённых unit-тестированию. А вот тему приёмочного (acceptance) тестирования многие авторы стыдливо обходят молчанием, потому что оно получается какое-то то не очень agile. Но и отказаться от него тоже не получается. Как можно организовать приёмочное тестирование, чтобы оно в максимальной степени соответствовало духу agile? Приходите, обсудим.

    Дмитрий Всехвальнов – Unit testing XML
    (Ведущий разработчик и архитектор Luxoft, Ping Identity ODC)

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

    Андрей Бибичев – <Безудержный Refactoring: как не убиться об стену>
    (Директор по Техническому развитию компании CustIS)

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

    Илья Гаврилов – <Тестирование в Agile проектах>
    (Тест Менеджер, Exigen Services)

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

    Андрей Сатарин – <Введение в непрерывную интеграцию>
    ( Сотрудник отдела качества, CustIS)

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

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