Коллеги, а можно ли связать файл проекта с MS Outlook чтобы из проджекта экспортировать расписание по задачам в календарь?

Компания «e-Style ISP» при поддержке компании «Организация времени» приглашает Вас 8 июля 2008 г. в 10:00 принять участие в открытом тренинге-презентации «Тайм-менеджмент на Outlook и аутсорсинг IT».

Также будет организована Интернет трансляция мероприятия в прямом эфире.

Программа семинара:

( Подробнее... )

Можно посмотреть здесь http://blog-of-roman.blogspot.com/2008/07/msf.html
и здесь http://blog-of-roman.blogspot.com/2008/07/cmmi.html
Эти два конспекта предоставлены моими коллегами (первые три были мои)

Ничего общего с бизнесом, пожалуй что-то есть общее с программирование.

Меня, удивляют люди, которые мыслят по следующей схеме:

“Все успешные люди носят костюм, вывод чтобы быть успешным нужно носить костюм”. Для подтверждения еще подопрем это тем, что вон “бомжи костюмы не носят и поэтому они не успешные”.

Краткий ввод в курс булевой алгебры (может правда я ее путаю с алгеброй логики).

Если из A (”Человек успешный”) следует B (”носит костюм”), то это НЕ значит, что из B (”носит костюм” следует A (”человек успешный”).

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

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

Добрый день, сообщество.
Обнаружил тут, что что по расчету длительности проекта "критическим путем" (именно примеров) ничего и нет. Может конечно плохо искал.
И решил я накидать маленький практикум, который помог бы сотрудникам компании немного разобраться в сути.
( практикум )

Хотелось бы услышать отзывы. Заранее спасибо.

Френды, я буду читать курс по "теории ограничений" в АНХ. Но времени мало 12 часов. Хочу совместить очное и дистанционно общение со студентами. Исследую какую часть материала отнести в очку какую в дистанционку. :)
Кто знает как правильно нагуглить информацию про вебинар и подобные ему формы дистанционного общения? Мне интересно насколько сейчас технологии позволяют технологии лекции\семинары\тренинги перевести в дистанционное общение. Чего они требуют взамен? Например толщина канала и вычислительные способности... качество звука, а может быть и изображения. Какие стандартные программы? Какие специализированные? Скока денег стоят? Отвечать можно в комментах или тут (ссылка)

housematehorror
Horror stories from the world of shared living spaces. EEK!

Привет, всем !

Недавно начали в своей конторе серию семинаров о различных методологиях управления проектами. Что-то вроде вводных курсов, стартовых точек, для тех, кто хочет понять какие конкретно из них ему стоит изучать. Решил опубликовать конспекты для тех, кому интересно. А может кто-нибудь еще и прокомментирует, тогда будет совсем здорово.
Пока есть про PRINCE2, PMBOK и 6 сигм.   http://blog-of-roman.blogspot.com ;

Итак прошло фактически пол года,  с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 1 и часть 2).

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

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

Итак начну из далека.

Пусть есть электрик Вася, сидящий на зарплате, и пьющий водку в рабочее время. И вдруг к этому Васе приходит белочка и он  думает , а чего это я водку все пью, лучше бабла подзашибу. Но блин, даже если я начну вкалывать, то дай бог мне подымут зарплату на 20%, лучше я пойду к своему начальнику и скажу, мол давай работать сдельно. Так Вася и делает. Приходит к начальнику и говорит, так мол и так, с водкой завяжу, сдельно работать будем и тебе лучше (я в пять раз больше сделаю и качественней делать буду) и мне лишняя денюжка в кармане. Начальник чешет голову и говорит, ладно Вася - починка розетки - 5 рублей, починка короткого замыкания - 10 рублей, полная проводка квартиры - 100 рублей. Если у заказчика все после этого через неделю сгорело - то с тебя вычет в двойном объеме. Проходит год, Вася шустрит, иногда правда клиенты ругаются, но суммарно все довольны - Вася при деньгам, начальник троих других электриков уволил, так как Вася за троих справляется, клиенты - счастливы не нюхать перегар Васи.

История вторая - есть Петя строитель. Так же самая картина маслом, но пьет он не водку, а пиво. И договаривается за 1000 положенных кирпичей. Начальнику тоже по душе, чтобы Петя работал и компания на нем деньги делала. Да, и теперь кладет кирпич в три раза быстрее, и при этом теперь больше его построек соответствует ГОСТу 1274-32-12б по укладке кирпича.
История номер три - есть Коля, модный массажист, делающий все виды массажа начиная от Боливийского и заканчивая массажем под названием “Рессора Белаза”. Коля, правда пьет уже не водку и пиво, а коньяк (не меньше 3 звездочек), но это мало что меняет. И вот он приходит к начальнику и говорит, а давайте я буду работать сдельно и буду делать все массажи в 5 лучше и в 5 раз быстрее. И вот тут начальник, выпучив глаза, говорит Коле…. Коля, а с коньячком-то видно пора таки завязывать, ты что с дуба упал в 5 раз быстрее массаж делать? Да и как мы будет проверять, что ты в 5 раз качественнее массаж сделал? У тебя что же есть массажеметр? Так, что пойди ка ты Коля, отдохни немножко и с свежими мозгами назад на зарплате работать возвращайся.
Ну, теперь более серьезно. Какова разница между вариантом Васей, Петей и Колей? А разница то, что в первых двух вариантах есть достаточно простое количественное измерение (связанной с доходом) сделанной работы и определенный (разумно измеримый) качественный уровень. В третьем же варианте, хотя количественное измерение есть, но оно не связанно с доходом и качественного измерения нету.

И теперь мы наконец возвращаемся к нашим горе-программистам.

С одной стороны, программисты (включая меня) очень хотят чисто сдельную оплату. Причем не просто сдельную оплату (такую как имеют freelancer’ы), а сдельную оплату внутри фирмы, когда дополнительной работы по поиску клиентов, ведению бухгалтерии у них нет, а вот денег можно зашибить дофига, если ты достаточно эффективен.
Кстати, коротенькое замечание сдельная = fixed cost за задачу, а не почасовка. Почасовка - это фактическа зарплата, просто в зависимости от того, сколько отсидишь на работе. Концептуально почасовка не меняет отношения к тому на сколько быстро хочется решить задачу. Я бы даже сказал, почасовка наоборот двигает человека в направлении растягивания задач.
Так вот, возвращаясь к тому, что программисты хотят сдельную оплату. Есть исследования, которые показывают, что отличный программист может быть эффективнее среднего в 10 раз. Соответственно, перед глазами мелькают цифры с 5-6 нулями за год
И вроде все было бы хорошо, если бы не
- Отсутсвие типовых задач
Фактически сама по себе - это не проблема, но я покажу, во что оно выливается ниже.
Тот же электрик или строитель, да и даже массажист имеет вполне ограниченный набор типовых задач. Их может быть скажем сотня, но все таки сотня разных задач - это вполне разумное число. И эти задачи можно записать.
- Отсутсвие количественной оценки задачи
Вот это проблема, которая вытекает из первой. Так как типовых задач нет, то все задачи не типовые. Для типовых задач, даже если их нельзя оценить впрямую, то можно оценить чисто статистически, сколько они занимают и какую прибыль они приносят. В случае, если же задачи не типовые, то начинается проблемы с их оценкой. И дай бог, если задачу можно оценить каким-то разумным методом. В программировании же, оценка чаще всего очень эмпирическая и +/- 30% даже на небольших задачах считается вполне неплохой точностью.  В добавление к этим проблемам, еще зачастую единственный человек который может дать оценку - является тот самым программист, работающий на проекте. И начальник никак не может проверить, дал ли он настоящую оценку или завысил ее в три раза.

Соответственно, начальник не может вывесить прейскуранта (как было сделано для Васи и Пети).

- Отсутствие измеряемого качества

Основным методом измерения качества программы (в основном) является оценка количества багов. С другой стороны, любой программист вполне может сказать, что программа может иметь сумасшедшие проблемы с внутренним качеством (архитектурой) и при этом иметь не так много найденных багов. И может быть наоборот, множество мелких багов, при том, что внутренняя структура достаточно нормальна.
Итого, суммируя три вышеперечисленных проблемы. Программист, который от компании хочет полностью сдельной оплаты, похож на того массажиста (давайте я буду делать массажи в 5 раз лучше и 5 раз быстрее). Вроде как и пожелание разумное, но до тех пор пока не изобретут массажеметр или программистозатратометр, то фактически все параметры работы являются субъективнымы, так как и оценка размера задачи и оценка качества программы не является объективной величиной.

И поэтому в ушах начальника это звучит так “Давайте я увеличу мое субъективное вложение в 5 раз, а вы мне увеличите объективную зарплату в 5 раз”. Так в жизни не бывает, что субъективное оценивается равным объективному. И кстати, именно поэтому хорошие программисты получают зарплату в 2-3 раза больше средних, а не в 10. Так как они только субъективно в 10 раз эффективнее, и то непонятно по чьим измерениям, когда же субъективное конвертируется, то на выходе получает большая в 2-3 объективных раза зарплата.
Фух… Что-то я начал запутываться, но думаю вы меня поняли. Вся проблема именно в отсутствии объективных оценок. Поэтому думаю к такому виду сотрудничества как я писал в первых частях - IT бизнес таки не придет.

Воооот… Ну и очень хотелось бы услышать ваши мнения, комментарии и идеи.

Дополнение N1: Итак, давайте, оценку = estimate из понятия абстрактного (а-ля сферический конь в вакууме) переведем на понятие реальное. Есть конечный человек которые делает оценку задачи.

Ситуация 1. Оценку делает менеджер, которые с кодом не работает. Я не верю, что человек не работающий с проектом может дать насколько нибудь разумную оценку.

Ситуация 2. Оценку делает каждый для себя. В таком случае, люди могут завышать оценку, тем самым выбивая деньги из фирмы.

Ситуация 3. Оценку делает team lead или другой опытный разработчик имеющий большой опыт на проекте. Это достаточно разумная практика, но в ней есть две проблемы. Даже team lead не дает точную оценку и очень обидно будет программистам, которые недополучат денег из-за ошибки team lead’а. Вторая проблема, что ситуация 3 вырождается в ситуацию 2 для самого team lead’а. То есть самый опытный человек делает оценку для самого себя и может ее завышать.

Учитывая, что весь этот сыр бор с программистским синхрофазотроном обсуждается именно для самых толковых программистов, то Ситуация 2+3, крайне важна. Непонятно, кто будет оценивать оценку team lead’а.

Дополнение 2. У многих возникает удивление. Типа, если программисты станут в 3 раза быстрее работать, какого фига они сейчас так не работают. Так что, эти заразы, работают не на полную мощность.

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

dwseason4
A journal where the alternative fourth season of the TV show Doctor Who is being written.

lol_comics
Keep youself smiling at the little things with some funny comics.

bikes
A community for everyone who loves bicycles, motorbikes, and more.

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

- Я могу сделать это лучше других.

Потрясающая формула, которая способна превратить вашу жизнь в ад (просто потому, что дел станет больше чем времени).

- Я толком не могу контролировать, что они сделают это качественно.

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

Если действие действительно должно быть сделано качественно придумайте не как вы должны проверять качество, а как подчиненный должен вас удостоверить в качестве.

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

- Я же трачу на это деньги.

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

Дополнение от Станислава Малкина:

- Программисты не любят переходить к следующей задаче

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

Я думаю все помнят этот анекдот с длинной бородой:

Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!

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

На самом деле, эта одна из самых моих нелюбимых фраз (от программистов) что-нибудь типа “Не трогай это, оно очень ненадежное/сложное”.

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

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

Итак, почему мне это не нравиться?

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

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

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

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

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

( Read more )

По данным, приведенным социологами РАН, бедные (живущие за чертой бедности) и относительно бедные (балансирующие на грани), по состоянию на весну 2008 года, когда проводилось исследование, составляли 43 процента от населения страны, что на 5% больше, чем в 2006, и на 10% больше, чем в 2003 г. Еще около четверти населения составляют малообеспеченные люди.

( Read more )

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

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

Всё замерло, притихла ночь,
Исчезли с улиц шум и крики,
Все ждут начала всех начал,
Великого прихода Смуты!

А между тем, в тиши квартирной,
Роясь в делах и суете мирской,
Сижу, и думаю о том,
Что Бог их - это Рынок, Деньги, Шоу...



бляпиздец, еще немного, и начнется, а потом до утра будут на улицах гадить от радости/или с горя :\

фотографии: http://anatrrra.livejournal.com/84732.html

хроника вечера 25 июня: http://streetsmedia.livejournal.com/117915.html

хроника и лирика 25 июня: http://maskodagama.livejournal.com/558285.html

обновления о злоключениях задержанных активистов 25 июня: http://maskodagama.livejournal.com/558555.html

социальный подтекст истории: http://taoom.livejournal.com/2974.html