воскресенье, декабря 31, 2006

С Новым Годом!

Всех поздравляю с наступающим Новым 2007 годом!



В Новом Году нас ожидает масса всего интересного в мире программного обеспечения.

Вот список того, что, как мне кажется, выдвинется на первый план в будущем году:

  • Распространение Windows Vista и как следствие этого (поскольку одновременно с Vista вышла .NET Framework 3.0) - широкое использование Windows Presentation Foundation для программирования пользовательских интерфейсов)?
  • Более широкое распространение параллельного программирования? Уже скоро у нас будут многоядерные и многопроцессорные машины ... а что с программами, которые мы пишем? Не пора ли нам все учить Erlang?
  • Поиск, основанный на репутации - (wikiasari)?
Вот здесь: http://www.artima.com/forums/flat.jsp?forum=270&thread=189962 находится неплохое обсуждение тенденций в программном обеспечении на будущий год - интересно.

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

Ну и конечно - все хорошо в меру. Я пошел праздновать - чего и вам желаю!

Ещё раз с Новым Годом!!!

среда, декабря 27, 2006

Всемирная помойка 2: Wikiasari

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

Так вот, идея наконец была подхвачена! :-) Вот уже 4-й день все новостные сайты и блоги сообщают о новой инициативе основателя Wikipedia Джимми Уэйлса (Jimmy Wales) - "революционной" поисковой системе - Wikiasari (от слова wiki, что на гавайском означает "быстрый", и слова asari, что переводится как "тщательный поиск" с японского).

Первое сообщение, судя по всему, было сделано британской The Times: Founder of Wikipedia plans search engine to rival Google.

Итак, о чем собственно речь? Вот что говорит по этому поводу сам Джимми:

"Поиск - часть фундаментальной инфраструктуры интернет. И, в настоящее время, он не работает.

Почему он не работает? Он не работает потому же, почему обычно не работает не свободное программное обеспечение: недостаток свободы, слабое участие общественности, недостаток прозрачности. Теперь мы изменим все это.

...

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

И вот ещё цитата (по The Times): "На самом деле, если подумать то одной из основных задач поисковой системой является задача принятия решения - эта страница хорошая или эта страница плохая. У компьютеров очень плохо получается решать эту задачу, зато у самих людей получается очень неплохо! Нам достаточно просто посмотреть на страницу пару секунд мы можем определить хороша страница или плоха".

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

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

воскресенье, декабря 24, 2006

Про бонусы

Вступление
Очень часто последнее время попадаются вопросы и рассуждения на тему "бонусов". Нужны бонусы или нет, приносят ли они эффект или нет, привыкает ли человек к бонусам или нет, к каким "событиям" в жизни команды/проекта/коллектива стоит приурочивать бонусы и так далее.

Мне тоже охота порассуждать на эти и близкие к этим темы.

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

А зачем все эти бонусы нужны

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

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

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

Ведь бонус, он только для того и нужен - чтобы добиться чего-то - не так ли? Если у всех работников будут общие цели, то их будет удобнее добиваться.

Типы бонусов

Бонусы, в моем понимании бывают нескольких типов:

  1. Деньги
    • определенный процент от зарплаты выплачиваемый в случае качественной работы в течение какого-то срока времени
    • ежегодный денежный бонус к новому году/годовщине компании/ещё какому-то празднику
    • премия по итогам работы над проектом

  2. "Полезные для работника"

    • оплата отпуска в далекой южной стране
    • оплата абонемента в бассейна, фитнесс-клуб
    • оплата обучения по специальности
    • оплата поездки на выставку, семинар, конференцию
    • оплата сдачи экзамена (например MS сертификации)
    • медицинская страховка

  3. "Приятные безделушки"
    • В Microsoft, как известно, принято после успешно выпущенного продукта выдавать участникам проекта специальную награду "ShipIt!", о которой существую неоднозначные мнения.

      Вот например Элдар Мусаев очень даже доволен своей.

      А, например, автор знаменитой книги Microserfs Дуглас Коупленд, показал в ней
      далеко не самое хорошее отношение сотруников к этой награде:

      If you ship on time you get a Ship-It award: a 12-x-15-x-1- inch Lucite slab - but you have to pretend it's no big deal. Michael has a Ship-It award and we've tried various times to destroy it - blowtorching, throwing it off the veranda, dowsing it with acetone to dissolve it - nothing works. It's so permanent, it's frightening. (http://www.wired.com/wired/archive/2.01/microserfs_pr.html)

    • Майки, футболки, толстовки с логотипом фирмы
    • Значки, ручки и прочие сувениры
    • Почетные дипломы и грамоты, звания "Лучшего сотрудника" года, месяца и тому подобное
    • Благодарности, объявляемые публично в присутствии всех или многих сотрудников компании
Цели компании

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

  1. Компенсация зарплаты.

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

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

  3. Попытка повысить профессиональный уровень сотрудников.
Цели, как они представляются сотруднику

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

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

Заключение

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

пятница, декабря 22, 2006

Хостинг поменялся

Поменял хостинг с wordpress на blogger - в течение некоторого времени возможны проблемы, свзанные с переносом статей и "обживанием" на новом месте

четверг, декабря 21, 2006

Пояснение об анонимности в Сети

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

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

(я конечно понимаю, что кто-то может написать что-то, “войдя в систему” под ником исходного автора, или сидя за его домашним компьютером, но это, как мне кажется, немного другая тема).

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

P.S. Анонимностью часто называют невозможность вычислить “физического” человека по его присутствию в сети - об этом речи нет. Скажем так человек должен сам решать должен ли его”авторский идентификатор” иметь какое-то отношение к его реальной жизни. Это отдельная большая тема.

RSDN: Влияние интернета на качество знаний

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

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

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

Кроме того, в интернет довольно плохо продумана концепция авторства — то есть читая ту или иную информацию ты не всегда можешь понять
насколько можно доверять ей. Ведь наша оценка во многом основана на субъективном восприятии “репутации” того или иного человека —например если я вижу в форуме C++ сообщения от Павла Кузнецова, то ещё до прочтения я буду доверять ему больше чем сообщению от Васи Пупкина. Потому что “репутация”. В интернет понять кто является автором того или иного сообщения можно не всегда, а соответственно степень доверия этому сообщению может быть довольно трудно определить.Тот кто этого не понимает —вполне может нахвататься разного рода псевдонаучных теорий и быть искренне уверенным что они правдивы — просто потому что “печатному” слову доверие больше чем устному.

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

Всемирная помойка, или почему поиск не всегда помогает

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

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

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

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

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

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

( Между прочим такие системы вроде бы уже есть и разрабатываются, но конечно до массового применения им пока далеко. Проект пионера гипертекста Теда Нельсона Xanadu включал в себя обязательный copyright, то есть по сути систему гарантирующую авторство. Надо признать, что это очень интересный (особенно учитывая тот факт что он зародился ещё в 60-е годы), но совершенно провальный проект. )

Заметим, что поиск информации - это тот же выбор. Системы поиска, ранжирующие результаты по количеству внешних ссылок, по сути пользуются вторичным индексом. Человек, как мне кажется, ищет пользуясь репутационными критериями. А уже в результате этих репутационных критериев возникает желание сослаться натого или иного автора. Но не наоборот! Я включу книгу Страуструпа в свою библиографию не потому что его книгу уже включили другие, а потому что его репутация в моих глазах достаточно высока!

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

Гвидо Ван Россум рассказывает про Code Reviews в Google

Сегодня наткнулся на замечательное видео: http://video.google.com/videoplay?docid=-8502904076440714866

Здесь Гвидо Ван Россум (иозбретатель языка Python) рассказывает о Code Review системе, применяемой в Google. Помимо интересного рассказа, хочу отметить что это редкий случай когда раскрывается информация о том как именно устроен процесс разработки в Google, а не только рассказывается про то какие там хорошие повара и то что 20% рабочего времени каждый разработчик может тратить на собственные проекты.

В частности для меня новой стала информация, что:

  1. В качестве source code control системы в Google используется Perforce (кстати говоря как и в Microsoft, хотя там perforce вроде бы немного доработан напильником)
  2. Branches разработчики практически не используют - все работают в main trunk
  3. Code Review практики используются повсеместно и очень активно
  4. Черт побери у этих ребят почти ВСЕ web-based!!!

Лояльность работников - взгляд со стороны менеджера “среднего” звена

Привет,

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

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

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

Внешние и внутренние силы

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

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

Мы будем рассматривать только внутренние силы. Внутренние силы - это все те силы, которые не являются внешними :-)

Отталкивающие и притягивающие силы

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

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

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

Баланс сил

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

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

Менеджер

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

А что если мое начальство не согласится со мной?

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

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

Но зато потом Вы сможете сказать себе что вы сами себя уважаете. А разве может быть что-то приятнее?

Как нужно рекламировать себя и свою компанию

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

Microsoft начинала с Basic, и была вполне успешной компанией, когда на горизонте появился Borland. В конце 1983 года Андерс Хайльсберг (тот самый, который позже станет автором Delphi, а ещё позже главным архитектором C#) создает для Borland Turbo Pascal. Это была потрясающая для того времени программа - очень компактная и, кроме того, сочетавшая в себе текстовый редактор и компилятор.

Филип Канн (основатель Borland) очень быстро понял что делать. Он установил цену на Turbo Pascal в 49 долларов и 95 центов. Вот как выглядела реклама этого продукта в журнале Byte Magazine:

“Borland’s Turbo Pascal
is a giant step
in the right direction.”

Jerry Pournelle,
BYTE Magazine, April 1984
$49.95

Microsoft к тому времени была уже весьма крупной компанией, но даже они ничего не могли поделать - Turbo Pascal был великолепен для своего времени. В нем была интегрированная среда разработки! Это выглядело вот так:

В 1986 году Microsoft попытался сделать решительный шаг. Необходимо было наверстывать упущенное. Был подготовлен новый продукт. Microsoft Quick Basic 2.0, в котором Microsoft также представил свою первую интегрированную среду разработки (IDE).

Но ведь Microsoft отстал! Отстал на 3 года - это немало для любой сферы деятельности, а уж для рынка IT - огромный срок. Turbo Pascal тому времени уже имел версию 3.0. Необходимо было что-то делать, чтобы завоевать доверие рынка.

И вот именно в это время, PR работники Microsoft придумали великолепный на мой взгляд ход.

3 октября 1986 года Microsoft организовала пресс-конференцию. Были приглашены технические редакторы и авторы различных компьютерных изданий, для того чтобы познакомить их с текущей продукцией компании, и, в частности, с QuickBasic 2.0.

Однако, это была не просто пресс-конференция - Microsoft придумал удивительный и новый способ привлечь к себе внимание. Был устроен конкурс! В те времене журналисты, пишущие о компьютерах часто сами были программистами - любителями или профессионалами. Поэтому Microsoft предложила устроить состязание по программированию. Несколько заданий были положены в шляпу, после чего одна из них была вытянута представительницей отдела рекламы MS. Текст задания размножили и раздали всем участвующим.

Условия были такие: любой из журналистов имеет право пользоваться системой и языком программирования по своему выбору. Также в конкурсе будет участвовать представитель Microsoft - Билл Гейтс, который будет работать на QuickBASIC 2.0. Победителем объявляется тот, кто первым успешно напишет программу, которая справится с заданием.

Среди участников были весьма неплохие программисты, например в конкурсе участвовал Charles Petzold, а также компьютерный журналист Jeff Duntemann. Некоторые, в том числе Duntemann воспользовались Turbo Pascal. Однако, конкурс окончился и победителем был признан … Билл Гейтс!

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

Заметим также, что ведь Билл Гейтс мог и проиграть. Есть мнения, что задачи были специально составлены так, чтобы у Гейтса и QuickBASIC было преимущество, но так или иначе - Гейтс выиграл, а мог и не выиграть, даже зная задачи заранее. Мне кажется важно осознать, насколько PR отдел Microsoft верил своему шефу, насколько они были уверены в его победе - ведь проигрыш принес бы прямо противоположный результат.

Ссылки

  1. Antique Software: Turbo Pascal 1.0 - здесь можно скачать рабочую версию!
  2. Microsoft Basic Version Information
  3. Интервью Jeff Duntemann, одного из участников конкурса “Storm the Gates”
  4. Книга Programming Windows, в одной из глав которой Charles Petzold описывает конкурс “Storm The Gates” (Тоже самое, но по-русски: Программирование для Windows)
  5. Книга Fire in the Valley -замечательная книга по истории персональных компьютеров. (Тоже самое, но по-русски: Пожар в долине)

Что такое kludge?

В программировании есть понятие kludge - это корявый способ исправления ошибки в программе, часто исправляющий не саму ошибку а её проявление. В блоге Чарльза Петцольда сегодня я наткнулся на замечательную цитату, очень точно описывающую смысл этого понятия:

    “Say you’re writing a program and you discover you’ve done something wrong, like every time you try to use the program, a button pops up. Most programmers go in, analyze their program, find out what causes the button to pop up and cure it so it doesn’t do that. [John] Draper [aka Captain Crunch] would go in and code around the button so when the bug occurs, the program knows it’s made an error and fixes it, rather than avoiding the error in the first place. The joke is, if Draper were writing math routines for addition and he came up with the answer 2 + 2 = 5, he would put a clause in the program, if 2 + 2 = 5, then the answer is 4.”
    — Chris Espinosa as quoted in Steven Levy, Hackers: Heroes of the Computer Revolution (1984), ch. 13

Делегировать или нет - вот в чем вопрос?

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

“Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить…Способность к делегированию - это одно из качеств, которое вы, лидер, должны постоянно совершенствовать” - Дж. Ханк Рейвотер - “Как пасти котов”, Питер, 2006

“Some swing a lot toward the technical and risk losing touch with their team and thereby building the wrong thing or missing their dates. Some swing toward the management, losing touch with the technology and losing the respect of their developers. Of the two, swinging too much toward the technology is the biggest danger, but only by a little.” Chris Sells, Microsoft Program manager.

“При большом объеме задач, явно не соответствующих вашей компетенции и стоимости вашего времени, подумайте о покупке внешней услуги - секретаря, технического помощника и.т.п” Глеб Архангельский. “Тайм-Драйв”

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

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

Кроме того, делегирование - это способ масштабирования работ. Если все задачи проходят через одного человека, то в какой то момент этот человек становится “узким местом”, “бутылочным горлом” , на котором застревают все дела и вопросы. И делегирование, правда уже не рутинных задач, а руководства какими-то направлениями (вполне себе по Стивену Кови) - это вероятно единственный способ избегать бутылочного горла.

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

Делегирование - это не только разгрузка от рутинной работы и возможность “масштабирования” руководства. Это ещё и способ хорошенько забыть все, что ты когда-то умел делать. Эти самые рутинные задачи порождают в нас мысли о том , как их выполнение автоматизировать. Это постоянные мучения с системой контроля версий позволяют нам понимать почему её нужно поменять на другую ( уж извините - примеры будут из программирования, так как это область с которой я лучше знаком). Это жутко медленно выползающее окошко Output заставляет нас говорить о том , что компьютеры нужно поменять на новые. Мы можем видеть прогресс проекта, только если мы занимаемся рутиной.

Большая часть работы, которой мы занимаемся, программирования - это именно рутина. Продумать алгоритм, разработать сложную и элегантную архитектуру - это здорово и интересно, но львиную долю времени занимает не это. “Технические вопросы, как многие “менеджеры” их называют , могут занимают существенно больше времени. Как правильно устроить структуру проекта в системе контроля версий? Как правильно хранить ресурсы, так чтобы их было удобно локализовать? А как можно осуществить мониторинг запуска процессов в Windows? А почему ошибка не правильно передается в ATL attributed проекте? Все эти и подобные им вопросы возникают очень часто и в большинстве случаев являются хорошими кандидатами на делегирование.

Вот только в результате - теряется “чувство” проекта. Долго, долго тебе кажется что ты все это знаешь и понимаешь, а когда в какой-то момент кто-то заболевает и тебе приходится слезть со своего менеджерского пьедестала и спуститься в окопы, то оказывается что ты все забыл! То есть теория-то вроде есть, а вот практика … с ней хуже. Все верно, многое вспоминается довольно быстро, но тем не менее.

Рутина - это тренировка! Тренировка для мозгов и для рук. У культуристов есть такая поговорка “Чтобы много жать - нужно много жать”. Мне кажется, она справедлива не только в спорте. Технический менеджер конечно же должен делегировать задачи, особенно в большом коллективе, иначе он станет узким местом. Но он ни в коем случае не должен совсем сбрасывать с себя “рутину”. Иначе он перестанет быть частью команды - он станет эдаким живым Excel-ем, который просто каждое утро опрашивает всех о состоянии дел и считает что он знает в каком состоянии находится проект.

Не делегируйте все! Знайте меру! Это тяжело, но необходимо.