Category: россия

Category was added automatically. Read all entries about "россия".

cartoon

Том ДеМарко приезжает в Москву

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

Приезжает в первый раз. И не один, а вместе с Тимом Листером (соавтор Peopleware), Питером Хрющкой (один из соавторов ДеМарко в "Балдеющих от адреналина..."), и остальными своими коллегами из Atlantic Systems Guild, кроме Стива МакМиллана.

Они в пятером прочтут трехдневный семинар 28-30 марта. См. программу.

Это, безусловно, самое значительное событие в общественной жизни российского IT за всю его историю. Кто-то может считать иначе, но мне кажется именно так. Я иду.
cartoon

Еще один открытый тренинг, 21-22 ноября, Москва

Как и в прошлый раз в сентябре, 21-22 ноября я выступаю приглашенным гостем на тренинге Саши Орлова, Москва. “Управление командой” и “Карьера менеджера”.

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

http://gaperton.livejournal.com/38349.html
"Есть две интуитивных человеческих реакции, которые приводят к провалу проектов. Одна из них касается управления приоритетами - люди интуитивно пускают работы, по которым понятно, что делать надо, вперед, а те, в которых непонятно что делать для решения - откладывают. Второе - при выдаче задания подчиненным люди пытаются решить проблему самостоятельно, и выдать указания в терминах решения, но не проблемы, которую озвучить "забывают".

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

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

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

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

Осталось 5 мест. Регистрируйтесь на сайте.
http://www.happy-pm.com/blog/?p=3116
cartoon

Конференция SoftwarePeople

Подвердил свое участие, и пришел спам :). Ну, что тут можно сказать. Организаторы поняли меня буквально, и теперь придется включить план мирового господства в доклад в качестве примера. Уписаццо. Ну potan , радуйся. :) Теперь я возьмусь за этот план всерьез! Хо-хо-хо-хо-хо! (типо зловещий смех) :) 

 
Спешим сообщить посл едние новости конференции Software People 2009, которая состоится в Москве 21-22 мая.

Свое участие в конференции Software People 2009 подтвердили ведущие эксперты в области управления процессом разработки программного обеспечения. Вот некоторые из них:

Асхат Уразбаев (ScrumTrek) проведет интерактивный мастер-класс «Игра-симуляция – управление командой в agile при помощи доски задач».

Влад Балин, известный в форумах под ником gaperton, в докладе «Декларативное планирование» расскажет о новом подходе в составлении планов с помощью которого можно запланировать даже мировое господство :).

Александр Орлов поделится мыслями о чем, по его мнению, не договаривает Том ДеМарко в докладе «Человеческий фактор».

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

Юрий Шиляев (ARTICS Internet Solutions) выступит с докладом «Самоорганизующаяся команда: миф или реальность»

Приходите на сайт www.softwarepeople.ru, читайте новости, статьи экспертов, следите за событиями, участвуйте в акциях наших партнеров и регистрируйтесь на Software People 2009!

СПЕШИТЕ! РЕГИСТРИРУЙТЕСЬ! Количество мест ограничено!

! Специальное предложение Стоимость участия при регистрации до 17 апреля – 7 200 рублей.

Более подробную информацию о конференции Вы можете получить на официальном сайте мероприятия www.softwarepeople.ru или по телефону +7 (495) 775-1543 ext. 140

С наилучшими пожеланиями,
Екатерина Егорова

cartoon

Как меня чуть не уволили

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

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

За тот год мы успешно закрыли несколько совершенно потрясающих проектов. Во-первых - нам удалось поднять производительность работы сервера на построении исторических данных о котировках в 10 раз, за счет ввдедения модификаций на прикладном уровне (предрассчитанные одноминутные агрегаты). Во-вторых - разработать архитектуру и прототип решения, демонстрирующий увеличение производительности сервера еще в десять раз (за счет модификаций системного уровня - замена подсистемы работы с диском, мы вдвое превзошли MS SQL по производительности за счет компрессии котировок на лету).

Знаете, что это означает? Сокращение количества серверов на ферме в десять раз (с сотни до десятка), при улучшении их реактивности в 10 раз. И это еще не все. В третьих - нам удалось за тот год сделать невозможное - мы ускорили аналитическую обработку данных на клиенте в 4 раза на маленьких объемах данных, и в 25 (!) раз на больших объемах (за счет идентификации и устранения _всех_ O(N^2) алгоритмов, накопившихся в движке обработки данных за долгие годы). Последний проект был закрыт в три раза быстрее, чем планировалось - мы справились за 2 месяца вместо 6-ти.

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

Говорю правду и только правду. За то и только за то. Что я. Послал на адрес рассылки. Московского офиса. Две замечательных статьи. Джоела Спольски. На русском языке. Не верите? :))) Очевидцы подтвердят :))). Вот первая статья:

О вреде премирования
http://local.joelonsoftware.com/mediawiki/index.php/О_вреде_премирования

А вот вторая.
Голый шеф-повар против биг-мака (на русском найти не смог - но тогда была)
http://www.joelonsoftware.com/articles/fog0000000024.html

Бред, не так ли? :) Я сам не верил. :) Сейчас все объясню по порядку.

Начать надо с того, что в то непродолжительное время CEO у нас был фантастический мудак. Скоро вы сами это поймете по рассказу, я не буду называть его фамилии и имени - определить его по моему рассказу невозможно, поскольку в тот период за 4 года сменилось 5 CEO (гы!), одним из которых я, кстати, восхищаюсь и считаю везеньем что посчастливилось работать по его руководством.

Наш герой последовательно делал блестящую карьеру. Начав работать в компании программистом, он дорос до руководителя группы, доведя свой проект до совершенно неподдерживаемого состояния. Потому, перед тем, как выдвигаться на CEO, он показательно и громко уволил своего лучшего программиста (чем изумил весь офис, и не только москву), свалив на него полный провал своего проекта и списав все грехи. После чего - он таки стал CEO, вызвав этим фактом истерику по всему R&D.

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

- Димон, ну вот скажи, - говорю, - какой именно вопрос ты собираешься ему задать?
- Как какой? - изумился Димон, - "Когда прекратится бардак в девелопменте", конечно!
- Димон, ну ты же знаешь что он ничего тебе толкового не ответит.
- Ну да.
- Зачем тогда вопрос задавать?
- А ты не будешь?
- Конечно нет. У меня нет к нему вопросов, я его давно знаю, мне и так все понятно.

А вот остальные парни оторвались. Читаем выпуск корпоративной газеты, пришедшей в PDF-e. Димон ржот.
- Что там? - говорю, - анонимные ответы пришли?
- Да ты почитай! - ржот Димон и начинает декламировать с выражением первый вопрос. Хоть вопрос был и анонимный - но в голосе Димона почему-то отчетливо прослушивалась противная интонация Ильюхи Пиркина. Или Димон так читал? Не знаю.
- "Насколько я припомина-а-а-ю, все проекты под твоим руководством завершились провалом. Объясни пожалуйста - каким и-и-менно образом ты можешь привести к успеху весь Product Developent?"
- Что-о-о?! - охуеваю я, - Ну ка покажи?!
Такого в официальной корпоративной газете я увидеть не ожидал. Народ жог. Новоиспеченный CEO - вяло и неумело отмазывался. Короче, весь офис был доволен. Чего и добивался наш менеджмент - все успокоились, и бунт на корабле был погашен в зародыше.

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

Во-вторых - внедрением методологий и вообще - процессами. Он полчаса обсуждал новую форму дизайн документа с одним из коллег - я это видел, особенное внимание они уделили цвету шрифтов. Все пункты этого документа кончались словом structure. Скажем, вы должны описать не только class structure, но также deployment structure, requirements structure, и performance structure (!!!), и так примерно 10 раз.

Кроме того, он был озабочен приведением в жизнь правила, вычитанного из знаменитой книги, созданной HR-ами Intel в порядке диверсионной деятельности - там рекомендуется каждый год увольнять 10% R&D персонала.

Не пугайтесь, ничего страшного - со всем перечисленным R&D его успешно посылала, и он был в последствии довольно быстро снят с должности, с формулировкой "провал performance management-а". Но мы говорим не о конце - а о периоде кульминации правления нашего героя.

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

И что вы думаете? Оказывается, CEO был подписан на рассылку mos. Оказывается, он умел читать по русски. Он прочел эти статьи, и их художественная сила окончательно сломала его хрупкую психику. Он собрал менеджмент в штатах, и зачитал "статьи Балина" на английском в своем паршивом переводе (ссылку в низу на автора и оригинал на английском чувак не заметил). После проникновенной речи и художественного перевода статии Джоела обратно на родной язык в своей обработке он получил молчаливую санкцию уволить ВСЮ команду Балина (то есть меня), успокоился, и поехал заниматься этим, то есть нашим увольнением, в Москву. Опять же, план по увольнению 10% выполнить получается, короче, CEO был, в принципе доволен.

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

В результате, увольняли меня две недели. Однако, "за плохую работу" CEO снял меня с должности, и перевел в другую команду программистом - на испытательный срок (!). Ускорение работы сервера в 10 раз CEO хотел объявить плохой работой, и не пустить в продакшн (должна же быть плохая работа, если за плохую работу снимают!) - но и тут ему не повезло, владелец компании заставил его такую классную штуку в продакшн пустить. Пришлось CEO ограничится тем, что аккуратно умолчать про наш прототип, который еще в 10 раз ускоряет сервер, и тихо свернуть дальнейше работы в этом направлении. А то совсем как-то странно получилось бы.

Через два месяца CEO попытался доказать, что испытательный срок я не прошел :). С чем был дружно послан командой, куда меня перевели, и менеджментом московского офиса. А еще через пару месяцев его самого сняли.

Вот, какой поразительной художестенной силой обладают статьи Джоела Спольски. Всем рекомендую :)
cartoon

Метод планирования тула Джоела Спольски

http://www.fogcreek.com/FogBugz/docs/60/topics/schedules/Evidence-BasedScheduling.html

bvn>Спасибо за ссылку, но интересен реальный опыт. Использовал кто-то подобные методики для оценки сроков выполнения проектов и если да, то оправдали ли они себя.

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

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

Продукт Джоела — первое движение в данном направлении из того, что я знаю. Что касается самого метода.
1) Оценивать плотность вероятности завершения проекта — это как раз то, что нужно. Это здорово, и очень правильно. По сути — это самый разумный подход к оценке трудозатрат и сроков.
2) Методы, компенсирующие тенденцию к систематической недооценке или переоценке сроков известны, например, так устроены методы PROBE, которые применяются в PSP/TSP. Метод, который рекомендует Джоел — обладает на мой взгляд рядом крупных преимуществ перед подходом PSP/TSP. Он проще, не требует ручной настройки, и существенно в меньшей степени напрягает исполнителей.
3) Одна потенциальная проблема у метода Джоела — он (насколько я понял) не учитывает возможную зависимость случайных величин сроков проекта, что должно приводить к занижению сигмы на больших проектах со сложными зависимостями. Однако, в типовом сценарии применения тула Джоела (насколько я понял, цикл maintenance или легкий agile-подобный процесс), когда создается одна задача на одну фичу, их прогнозы вполне можно трактовать как независимые, и этот фактор не играет, все происходит достаточно аккуратно.
4) Огромная сила метода Джоела, дающая ему преимущество над всеми методами, выдающими на выходе оценку плотности распределения, состоит в том, что у Джоела тул основывается на фактическом распределении вероятности ошибки прогноза, которое он снимает с программистов, в то время как остальные методы исходят из предположения, что прогноз имеет какое-то фиксированное предполагаемое распределение (нормальное, бета-распределение, extreme values distribution, и прочее).

Лично мне больше нравится подход с двойной или тройной оценкой срока, когда эксперт задает коридор значений, а не один прогноз. Также, я люблю проверять корелляции плана трудозатрат с прогнозами метрик объема. Это позволяет мне определять лажовость планов по формальным признаквм, не вникая в суть каждой мелочи. С другой стороны, это позволяет оценивать риски количественно — отсутствие данной возможности всегда было моей основной претензией к методам класса PSP/TSP и прочих, основанных на корелляциях LOC/hr.

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

Короче, как ни крути — а получается что метод Джоела крут. Великолепный продукт, сочетающий невиданную простоту использования для тулов данного класса, с применением наиболее разумной и продвинутой технологию планирования для выбранного типа входных данных. Если вы хотите получить контроль над сроками и прогнозами, и не хотите ничего для этого делать (то есть получить это почти бесплатно) — то я однозначно рекомендую тул Джоела. Блестящий продукт, который стоит своих денег.