![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
eagleson's journalLog in Create a LiveJournal Account Learn more
| You are viewing eagleson's journal Log in Create a LiveJournal Account Learn more |
 |
|
| Александр Орлов's Journal 20 most recent entries |
 |
Актуальное расписание тренингов Happy PM - на сайте.
(Расписание тренингов) Статьи (про карьеру, менеджерские навыки, мотивацию сотрудников и саморазвитие)
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
проведет бесплатный вебинар “Людям о нелюдях менеджерах” Время: 11 февраля, 17:30. Детали мероприятия тут, там же надо записываться. 3 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Отношение к работе в духе «с моей стороны пули вылетели» часто присутствует у молодых специалистов. Которые считают, что они лично могут достигнуть успеха, даже если сам проект, в котором они участвуют, провалится. Но иногда это отношение встречается и у зрелых инженеров. Вот, например, есть такая активность - верификация дефектов. Стандартная ситуация в проекте: тестировщики дефекты выставляют (например, в Bugzilla), разработчики героически дефекты исправляют (переводят в состояние FIXED). А проверять то, что дефект действительно был разрешен (перевести его в состояние VERIFIED) - это уже можно сделать перед самым релизом. Что интересно - многих тестировщиков, на самом деле, не так сильно волнует, действительно ли были разрешены те ошибки, которые они нашли. А программистов не так сильно волнует, действительно ли те фиксы, которые они предложили, работают в системе. То есть, одни дефект выставили (с их стороны пули вылетели), другие фикс положили в пространство кода (с их стороны пули тоже вылетели) - и все. J Очень редко встречаются тестировщики, которые проверяют, что «их дефект» разрешен, как только тот перевелся в состояние FIXED. Еще реже встречаются программисты, которые пинают тестировщиков, чтобы те проверили, что дефект действительно FIXED. Так и летают пули по проекту туда-сюда. А бедные менеджеры тушат пожары: «А-а-а, у нас к релизу много непроверенных дефектов. Нужно еще два дня, чтобы их все проверить!..» 2 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Чудесный ролик от гения карандашной анимации Макса Дорофеева - на этот раз об истории Waterfall’а:
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
11 февраля: бесплатный вебинар “Позитивное управление персоналом” 25 февраля: платный вебинар “Найм от забора и до обеда. Полный цикл поиска и оценки сотрудника” 2 марта: бесплатный вебинар “Внутренний маркетинг. Как воодушевить ваших сотрудников сделать что угодно?” 24 марта: платный вебинар “Найм, мотивация и удержание программистов” Notice: Вероятнее всего, я там тоже буду. То ли в качестве гостя, то ли в качестве слушателя - Вика мне еще не объяснила. Notice 2: Форма регистрации на webinary.com.ua иногда взглючивает. Поэтому если неожиднно она не показывает того вебианара, на который хотите записаться, пишите его название в комментариях. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Еще в ноябре мы вместе со Славой Панкратовым написали статью по одной из “Игр в ИТ”. В декабре статью опубликовали в журнале “Профессия - директор”. Теперь публикуем ее здесь: Чемодан, который носят сотрудникиАлександр Орлов Независимый консультант, автор проекта «Клуб Успешных Менеджеров Программистов», соавтор проекта «Управленческие игры: психология и политика, в которые играют сотрудники, начальники, заказчики и компании» «Игры» - часть теории транзакционного анализа, выдвинутой выдающимся американским психологом 20-го века Эриком Берном. В своей теории Берн рассматривал межличностные отношений с точки зрения человеческих транзакций или соглашений, сделок. Транзакции, имеющие в себе скрытую цель, он назвал «играми».
Например, один сотрудник говорит другому: «Это начальство совсем оторвалось от жизни, совсем уже не видит, куда идет проект. А нам, инженерам, расхлебывать.» Это человек исходит из позиции «я+, ты+, они-». Если же человек говорит: «Ну, конечно, у них все получается и у тебя получается. Вы-то тут уже два года работаете…», то это позиция «я-, ты+, они+». Целью любой игры является получение ощущений - «купонов», которые могут быть как положительными (золотые купоны), так и отрицательными (коричневые купоны). Золотые купоны человек в будущем сможет обменять на определенные выгоды для себя (например, на повышение зарплаты). А коричневые он сможет использовать, например, чтобы обосновать свой уход: «Меня в этой компании никто не слушает». Также возможны фальшивые золотые купоны - например, человек, испытывает фальшивое чувство торжества над коллегами, но обменять это чувство на повышение он не сможет (потому что руководитель видит, что человек просто строит из себя «супер-звезду»). Однажды, когда я руководил одной из команд в большом проекте (мы разрабатывали программное обеспечении), у нас случился казус. Инженеры в разных командах реализовали один и тот же модуль. Модуль был нужным, но существовал теперь в двух экземплярах. Обе реализации делали одно и то же, но внутреннее устройство у них немного отличалось. Перед руководителем проекта встала задача - решить, какой модуль оставить. Обе команды, разработавшие свою версию модуля, такой вариант решения не устраивал: «Это что же,» - говорили они, «может так оказаться, что мы зря писали?..» Руководитель, однако, считал, что нужно выбрать лучший модуль, а другой выбросить в корзину. Поэтому он попросил обе команды заполнить таблицу с плюсами и минусами обеих реализаций. Думаю, читатель может догадаться, что произошло. Естественно, каждая команда нашла больше плюсов в своей реализации, а больше минусов в чужой. Слова: «Вы понимаете, что мы не зря писали этот модуль?» все чаще звучали с обеих сторон. Стало понятно, что ситуация становится взрывоопасной. Руководитель решил принять компромиссное решение. Инженерам из разных команд, авторам модулей, предлагалось сесть вместе и сделать совместный модуль, взяв лучшее из обеих реализаций. Поскольку команды находились в разных городах, то совместная работа проводилась по телефону и заняла около двух недель. 1 comment | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Гильдия Менеджеров Программных Проектов приглашает на уникальный двухдневный курс «Промышленная разработка и эксплуатация ПО: управление и контроль», который пройдет 27-28 марта в Москве в гостинице Мариотт Гранд Отель. Курс был разработан специально для руководителей подразделений и департаментов, ИТ-директоров и вице-президентов по информационным технологиям компаний, не специализирующихся на ИТ, в зону ответственности которых входит управление созданием и эксплуатацией информационных систем для бизнеса.
Специальные модули курса рассматривают сложившиеся в индустрии разработки мифы, которые приводят к провалам проектов, неуправляемости процесса разработки и эксплуатации ПО, культивированию псевдо-творческих настроений, которые на деле способствуют размыванию ответственности при выполнении проектов и дезорганизации производственных и административных подразделений ИТ-департаментов. Подробнее на сайте Гильдии Менеджеров Программных Проектов post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Глава 2: Правила игры Я не виноват Когда проект идёт успешно, то вполне понятно, кого надо хвалить: нас! «Я сделал всё, что мог, для этого проекта, а потому результат налицо. Без моего великого вклада проект бы не преуспел даже на малую часть.»
Кого же мы можем обвинять в провале проектов? Точно не себя! Это всё те придурки!
Когда проект идёт плохо, мы склоняемся к мысли «Кто вообще мог надеяться на удачу в этом месте? Проект был обречён изначально, с этими клоунами в командах и ленивыми неудачниками, отвечающими за критические участки работы!» post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Глава 1: Введение О культурах Если из всей книги вы усвоите только одну вещь, то пусть ею будет это: культура имеет значение. И большое значение. Культура разработки приложений не то же самое, что методология разработки приложений. Под методологией понимается набор правил, которых надо придерживаться, а культура - это набор укоренившихся устоев, вокруг которых сплотилась группа людей. Методология может говорить людям как себя вести, а культура определеяет человеческую потребность вести себя определённым образом. Культура определяет эмоциональную реакцию людей на навязываемые правила. Если методология и культура не совпадают, люди инстинктивно чувствуют обеспокоенность, и методология встречает неприязнь. Если менеджер является приверженцем одной культуры, а его/её команда сплотилась вокруг другой, то все будут чувствовать себя не в своей тарелке, и произойдёт болезненное столкновение культур. В отношениях появляется антагонизм и прогресс тормозится. Конечно, если вы обладаете некоторой властью над кем-то - например как менеджер над своей командой - вы можете заставить их делать то, что вам нужно. Если всё, что вам нужно, это послушание, то никаких проблем. Именно так заключённых в цепях заставляют целый день дробить камни. К сожалению, я очень много раз видел, что этот подход не очень работает в индустрии разработки приложений. И вот почему: Хотя угрозы и принуждение могут заставить людей подчиниться, это не может пробудить в них добровольное сотрудничество. Вы можете кричать, визжать и наказывать сколько угодно, но без добровольного сотрудничества люди никогда не вложат в свою работу ни сердца ни души. В лучшем случае результаты будут так себе. Если вы хотите исключительных результатов, то нужно принять во внимание культуру. Следуйте за своими эмоциями Мы начнём сразу с вопросов с несколькими вариантами ответов, которые помогут исследовать вашу собственную реакцию на несколько разных аспектов разработки приложений. Ваши ответы покажут, насколько сильны ваши эмоции и насколько сильным может быть их влияние на то, какой культуры вы придерживаетесь. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Software Project Cultures Anthony Lauder (translated by Albert Mustafin) 2008 Предисловие Почему я написал эту книгу? Я взялся за написание этой книги почти 10 лет назад, потому что коллеги, клиенты и друзья просили меня об этом. Общим у этих людей было ощущение наводнения различными методологиями разработки приложений, каждая из которых прокламирует свои собственные «правила» управления проектами и разработки. Люди пытались понять, что имеет смысл на практике, а что просто хорошо выглядит на бумаге. Мне говорили, что трудно представить общую картину; детали захлёстывают с головой. Поэтому я начал писать книгу, предназначенную именно для таких людей. Она рассмотрит широкий диапазон методологий разработки приложений и объяснит, как они связаны между собой и чем различаются. После нескольких месяцев глумления над клавиатурой я выпустил несколько глав и был шокирован, когда несколько рецензентов из тех людей, кто побудил меня написать эту книгу, сказали: «Интересно. Но какая тут практическая польза?» Моё эго было малость подавлено, поэтому я перестал писать. Тем не менее вопрос практической пользы никуда не делся. Он всё время крутился у меня в голове. В течение нескольких следующих лет консалтинга я стал замечать, что и другие люди задают похожие вопросы:
Постепенно до меня дошло, что людям не нужно говорить как они должны работать, они хотели понять, почему разные люди делают работу по-разному. Они спрашивали меня не столько о методологиях, сколько о том, как методологии срабатывают или дают осечку в конкретных культурах разработки приложений. И не только это, но и:
Чем эта книга отличается от других? Эта разница между методологиями и культурами кажется важной. Никто о ней не писал, но люди спрашивали об этом. На рынке явно существовала пустая ниша, которая убедила меня вернуться к написанию этой книги. Эта книга показывает, как осведомлённость о культурах разработки приложений может отделить успех от провала в реальных проектах. Вместо лишнего теоретизирования книга на жизненных примерах углубится в то, какие бывают культуры разработки приложений, откуда они происходят и какое влияние оказывают. Три доминирующие культуры будут определены и разобраны в деталях наряду с четвёртой культурой, которая сейчас совсем мало используется, а потому вынесена в приложения. Мы посмотрим на историю каждой из трёх доминантных культур, их базовые предпосылки и методики разработки приложений, соответствующие этим культурам. Вооружившись углубленным осознанием культур книга исследует довольно интересный вопрос - как очень успешные компании изменили свои культуры. Также мы увидим, что для закрепления культурных изменений нужно больше, чем навязывание новой методологии в командах. Культура разработки приложений должна постепенно проталкиваться по культурной лестнице, изменяя один уровень за другим. Feedback The most important part of this book is you. You and other readers will know far better than I possibly can how relevant the ideas here are to your daily work. Do let me have your feedback. I am sure I can learn far more from you, than you could ever learn from me. Together, we can make future editions of this book more valuable to its audience. Thank you Anthony Lauder post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Гильдия менеджеров программных проектов (SPMGuild) - независимое международное сообщество профессионалов в управлении проектами разработки программного обеспечения - объявляет о запуске своего нового сайта. Новый сайт Гильдии менеджеров программных проектов открыт 3 февраля 2010 года по адресу www.SPMguild.ru Помимо основных разделов о Целях и Программе Гильдии, а также признанных экспертах, основавших Гильдию и руководящих ее деятельностью, сайт Гильдии содержит новый раздел с анонсами мероприятий, которые Гильдия планирует провести в ближайшее время, а также архив новостей о мероприятиях, которые проведены под эгидой Гильдии в прошлом 2009 году. Отдельный интерес для сообщества представит еще один новый раздел - Библиотека - в котором будут накапливаться наиболее интересные и полезные материалы менеджерской направленности, причем как перепечатки уже известных статей, так и эксклюзивные материалы экспертов Гильдии и других признанных специалистов отрасли. Как прокомментировал открытие нового сайта один из соучредителей Гильдии Дмитрий Башакин, который руководил проектом по запуску новой версии официального сайта организации: “Переход на новый сайт был нужен нам для того, чтобы реализовать новые идеи по Интернет-представительству Гильдии, которые родились за последние полгода в головах членов нашей организации. Начали мы с простого статического сайта, который помог ознакомить общественность с нашими основными программными документами и привлечь к работе в Гильдии десятки высококвалифицированных специалистов отрасли. Теперь мы выкладываем на наш сайт подробные отчеты о проводимых Гильдией мероприятиях (включая аудио и видео репортажи) и информацию о наших перспективных планах. В стадии активного становления находится раздел, содержащий разнообразную полезную информацию по управлению программными проектами, которая представит несомненный интерес для специалистов нашем по управлению проектами.” О Гильдии менеджеров программных проектов: Гильдия основана 19 мая 2009 года в Минске (Белоруссия) на конференции Software Engineering Forum. Цели Гильдии:
Подробнее о Гильдии:
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
В середине мая в Харькове пройдет 7-я серия полюбившегося многим тестировщикам сериала под названием SQA Days. Снова лучшие эксперты и практики в области тестирования и управления тестовыми командами будут делиться опытом. На этот раз в сени цветущих каштанов города Харькова. Что такое обычно SQA Days? Обычно это 300-400 человек тестировщиков, которые активно знакомятся, общаются, обмениваются опытом и проникаются докладами и мастер-классами экспертов, превращаясь из простых тестировщиков в тестировщиков с горящими глазами. Поэтому если вы сам занимаетесь QA, или руководите QA отделом - ваше место и место ваших сотрудников - на SQA Days. Срочно записывайтесь сами и записывайте сотрудников. (Записываться лучше заранее, потому что на на мастер-классах мест обычно не хватает.) Если вы давно работаете в тестировании - присылайте доклад. Наверняка, вам есть, чем поделиться с коллегами! Вероятнее всего, я там тоже буду выступать, поэтому буду рад увидеть всех в середине мая в Харькове. Ниже - официальный анонс. 14-15 мая 2010 года в Харькове (Украина) пройдет Седьмая конференция в области обеспечения качества ПО «Software Quality Assurance Days» Приглашаем Вас принять участие в работе 7-ой Международной конференции специалистов в области обеспечения качества ПО “Software Quality Assurance Days“, которая состоится 14 - 15 мая 2010 г в г. Харьков, Украина. SQA Days является конференцией №1 на пространстве СНГ и одно из главных мероприятий в Восточной Европе, посвященная обеспечению качества программного обеспечения. Вот уже 4-й год Software Quality Assurance Days предоставляет прекрасную платформу для обмена опытом, общения, знакомств для всех, кто вовлечен в ИТ сферу. SQA Days известна как нейтральная, немаркетинговая конференция, организованная тестировщиками для тестировщиков и поэтому наиболее четко представляет потребности многочисленных сообществ, связанных с обеспечением качества ПО. SQA Days это это возможность рассказать про свои достижения, показать, как эффективно использовать инструменты, методики и методологии. Ну и, конечно же, это новые полезные знакомства. Тематика конференции:
Целевая аудитория:
Продолжительность: 2 дня Организатор: ООО “Лаборатория тестирования” (SQALab) Контактная информация: Владислав Орликов +375 29 770 48 58 Приходите, будет интересно! Зарегистрироваться и получить скидку (Для читателей happy-pm.com скидка 5%. Чтобы ее получить - укажите кодовое слово “HappyPM” при регистрации.) Подать доклад на конференцию: org@it-conf.ru (докладчики, при утверждении темы доклада, - участвуют бесплатно!) Ждем вас на SQA Days - 7! post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. 28-го января выступал в Харькове на встрече сообщества IT Talk с комическими куплетами на тему “Visibility как фактор влияния на карьеру”. Возможно, кому-то будет интересно послушать-посмотреть: How Visibility Impacts Career</p>
View more presentations from Alexander Orlov.
Спасибо компании Data Art и лично Ольге Тарасовой за приглашение, Харьковскому Национальному Университету Радио-Электроники и лично декану факультета Компьютерной Инженерии и Управления Владимиру Хаханову за помещение (и книгу! :)), сотне харьковских коллег за то, что пришли послушать и обсудить. Очень рад был с вами со всеми познакомиться. Надеюсь, этот час вы тоже провели с пользой. 3 comments | post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Буквально недавно Влад Балин (aka gaperton) рассказывал о том, как справляться с рисками на открытом тренинге Happy PM. Для тех, кому тема интересна, есть возможность посетить тренинг от синьор менеджера и практика - Константина Кондратюка (вероятно, часть читателей помнит наше интервью с Константином). Поскольку управление рисками - одна из самых больших проблем в отечественном ИТ, то проект Happy PM всячески поддерживает этот семинар. Пришедшие на семинар слушатели получат:
Ниже - официальный анонс. Константин Кондратюк
Тренинг «Управление рисками» знакомит с теоретическими принципами и практическими приемами по выявлению и документированию факторов риска, оценке их потенциального ущерба и предлагает стратегии их смягчения. Будут рассмотрены риски при целеполагании, риски при управлении требованиями, риски в коммуникациях, вопросы практического использования в различных моделях жизненного цикла. Все практические задания, групповые дискуссии и игры направлены на особенности управления рисками в проектной деятельности и нацелены на применение полученных знаний в реальной жизни. В конце тренинга будет проведен тест для проверки и закрепления полученных знаний.
АудиторияТренинг предназначен для менеджеров среднего звена, руководителей проектов и специалистов. Требуемые знания и профессиональный опытДля прохождения тренинга не требуются специальные знания в области управления рисками, желателен опыт руководства или участия в проектах и знания в области общего менеджмента. Методы обучения
Записаться на тренинг “Управление рисками”! post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Если кто-то говорит: “Я работаю по 90 часов в неделю”, я отвечаю: “Вы где-то очень крупно обсчитались. Я езжу по выходным кататься на лыжах, встречаюсь со своими приятелями по пятницам и на вечеринках. У вас тоже должно хватать на это времени, а иначе вас просто обманули. Составьте список из двадцати дел, из-за которых вы проводите на работе 90 часов в неделю, и половина из них окажется чепухой - либо за вас их должен выполнять кто-то другой.” post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.  Картинка с tucowsinc.com Тестировочные конференции шагают по стране. Это не может не радовать. Когда я начинал тестировщиком, а было это в начале 2000 года, с конференциями было туго. Хорошо рядом были коллеги, которых можно было поспрашивать, да Брайан Марик вел свой ресурс testing.com (сейчас эти материалы находятся вот тут). Брайна Марик, правда, я обнаружил спустя 4 года :). Но не суть. А сейчас - учись, не хочу! То тебе SQA Days, то Test Labs, то Алексей Баранцев что-нибудь устроит, то Слава Панкратов тест менеджеров прокачает. А 23-го марта состоится еще одно событие - компания Microsoft проведет Microsoft QA Days. Выступать там будут не только ребята из Microsoft, так что материал обещает быть разнообразным. А организуют конференцию Лена Арсенева с CareerLab и Влад Орликов с IT-Conf, что означает, что организация обещает быть достойной. В общем, все тестировщики - срочно планируйте визит в Москву 23 марта. Должно быть интересно. Ниже - официальный анонс. 28 марта 2010 г. в Москве состоится конференция Microsoft Quality Assurance Day. Как обеспечить качество программного обеспечения? Какие методы тестирования наиболее популярны и почему? Что такое Testing Lab Management или как настроить и воспроизвести среду (environment) для тестов? Можно ли автоматически тестировать графический интерфейс и как это делать? Что нового для обеспечения качества появилось в последней версии Microsoft Visual Studio 2010? Что такое разработка через тестирование или test-driven development (TDD)? На все эти вопросы ответят эксперты ведущих компаний. Конференция призвана рассказать о новых возможностях Microsoft Visual Studio 2010 для тестировщиков, опыте внедрения и работе с новой версией. Участников ждут:
Целевая аудитория:
Место проведения: Москва, бизнес-центр «Крылатские Холмы», ул.Крылатская, д.17, корп.1., Штаб-квартира Microsoft Продолжительность: 8 часов (1 день) Стоимость: 5 520 российских рублей * * При оплате до 8 февраля стоимость 4 450 российских рублей. В стоимость участия входит оплата регистрационного сбора, оплата питания (обед, 2 кофе-паузы), пакет участника с раздаточным материалом.
Организаторы: ООО “Лаборатория тестирования” (SQALab)
Контактная информация: По вопросам регистрации Юлия Анискина j.aniskina@careerlab.ru +7 495 775 15 43 доб.140 По общим вопросам Елена Арсеньева, e.arseneva@careerlab.ru +7 495 775 15 43 доб.178 Владислав Орликов, info@sqalab.ru +375 29 770 48 58 post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Опытные: Статистические Значения Итак, начинающие стараются вложить свою веру в предписанные правила других людей. Вера, разумеется, без доказательств. Начинающим нужна уверенность, а не доказательства, а потому они следуют правилам без вопросов, работают ли правила на практике. Возможно, это пройдёт для начинающих, но не для опытных людей. Опытным нужно немного больше, чем вера. Им нужны доказательства. Если какое-то правило хорошо звучит, то опытный человек может взять его на вооружение как надо-проверить-на-деле правило, но проверка покажет, подтвердить или отвергнуть это правило. Постоянно несрабатывающие правила постепенно будут отвергнуты насовсем. А те, что подтверждаются на опыте, станут регулярно используемыми. В результате постоянных испытаний опытные люди всё меньше полагаются на предписанные правила и больше на проверенные «законы». Они составляют свой собственный свод статистических значений, помогающий им решать, что работает, что нет и при каких обстоятельствах. В книге Тома Демарко и Тимоти Листера Peopleware есть история забастовки под названием работай-по-правилам. В ней рабочие букввально следовали формально навязанным правилам (процедурным руководствам), и, разумеется, прогресс сильно застопорился. Знание, когда правилам следовать, а когда нет, очень важно для эффективной работы. Вот, где опыт играет главную роль. Статистические значения ближе к сердцу, чем заимствованные правила, потому что они являются нашими собственными детищами, рождёнными потом наших трудов. Они становятся тем, о чём мы старательно печёмся. Мы используем их не только для управления нашими действиями, но и для определения успешности себя и других. Так же как начинающие чувствуют эмоциональную несовметимость с методологиями, которые конфликтуют с заимствованными ими правилами, так и опытные сотрудники могут чувствовать сильную эмоциональную неприязнь по отношению к методологии, которая не соответствует их собственным статистическим значениям. Когда мы сталкиваемся с чем-то, что подходит под нашу статистику, то испытываем приятное чувство, закрепляющее нашу уверенность в наших данных. И наоборот, когда что-то противоречит нашей статистике, у нас появляется некомфортное ощущение неприязни. Увиденное или услышанное кажется нам неправильным, а потому раздражает нас. Конечно, вполне возможно, что опытные люди смогут составить из своих статистических данных методологию, пригодную для других, но это рискованное предприятие, так как начинающим не хватит опыта, чтобы воспринимать это не только как правила для слепого соблюдения. Эффективность статистических значений зависит не столько от абсолютного повиновения, сколько от здравомыслия и уверенности, основанных на личном опыте. Главная разница состоит в том, что предписанные правила - это нечто, что вы считаете правильным, а статистические данные - это то, что вы знаете как правильное глубоко внутри, потому что оно было не раз доказано на практике. Они отображают опыт, полученный на передовых, который и отличает опытных от начинающих. Продолжение следует … post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there. Многие приходят на наши тренинги с желанием научиться разрешать проблемы с коллегами, сотрудниками, начальством, заказчиками. И таки да, за пару часов эту тему мы изучаем. Даже попрактиковаться успеваем. Потом в отчетах читаю, как люди разруливают всякие конфликты на работе и даже в семье (были и такие случаи). Но потратить два часа на обучение может не всякий. Для тех, кто не может - специальная простая схема разрешения проблем:
Взято отсюда. post a comment
Originally published at Клуб Успешных Менеджеров Программистов. You can comment here or there.
Так вот, он рассказывал, что некоторые реаниматологи делают стремительную карьеру. Реанимируют практически всех, кто к ним попадает. Что это означает? Задача реаниматолога - снять приступ, оказать первую помощь, вернуть человеку на землю, и передать следующему специалисту. А что там дальше с человеком происходит - за это отвечает уже следующий специалист. А больной может умереть из-за неправильно проведенной реанимации. Но на карьеру реаниматолога это уже не действует. Отвечает “следующий специалист”. Что интересно, это происходит и в ИТ сплошь и рядом. Один синьор менеджер одной крупной компании в приватной беседе рассказывал такую историю.
Почему так получилось? Вероятно, человек бодро стартовал проекты, получал какие-то первые обнадеживающие результаты, а дальше говорил: “Ну дальше тут справятся и простые ребята”, получал свои звезды на погоны и шел наверх. Другой пример из жизни. В одной компании годами существовал фрэймворк для прогона тестов. Менеджер из одного регионального подразделения стартовал проект, частью которого было написание аналогичного фрэймворка. Зачем это делается - на уровне инженеров не понимал никто. В итоге через два года новый фрэймворк был-таки благополучно погребен. Но где в этот момент был предприимчивый менеджер? Где-то в другом месте. Виноваты одни, ответственность несут другие. Те, кто заложил причину неминуемого провала, получают плюшки и идут наверх. Есть в этом что-то несправедливое, а? Из-за чего так происходит? Тот же врач реаниматолог высказал интересную мысль, что из-за того, что нет обратной связи. Не проводится анализ того, что происходит с проектами. О чем говорить, если во многих проектах не проводятся ретроспективы или пост-мортем анализы? То есть люди рубят, рубят, рубят - не получилось. Вздохнули, и давай рубить дальше! Коллеги, чтобы организация работала эффективно, чтобы у людей было ощущение справедливости, система обратной связи должна работать. Хотя бы как-то. Чем эффективней, тем лучше. post a comment |
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
11 февраля, в 17:30 по Московскому времени Денис Войханский (автор зажигательнейшего 
Наверняка многие знают старый анекдот про стрельбу студента на военной кафедре. Ну, на всякий случай, воспроизведу:
)
В феврале-марте 2010 Вика Придатко выдаст серию из вебинаров по практическому поиску, найму, удержанию и мотивации программистов. Вика известна нашим читателям по выступлению на 
Любая игра подразумевает нескольких участников: я, ты, они. Например: я - руководитель, ты - сотрудник, они - остальные сотрудники. Или: я - сотрудник, ты - другой сотрудник, они - начальство. Для начала игры играющий человек должен считать каждого из этих трех участников либо плюсом, либо минусом.
27-28 марта Гильдия менеджеров программных проектов проведет свой первый тренинг. Тренинг необычен тем, что нацелен на довольно интересную аудиторию - ИТ директоров не-ИТшных компаний. Если вы сами являетесь таковым директором - приходите, думаю, будет очень полезно. если вы работаете в такой компании - присылайте своего директора. Будет полезно и ему, и вам. 
Начиная с этого момента книга Энтони Лаудера “Культуры программных проектов” в русском переводе будет выкладываться главами. Вначале - предисловие.
(Читателям happy-pm.com 
, 
(Срочная opportunity. До мероприятия 
(все выложенные на текущий момент части - 
На одном из последних тренингов был интересный слушатель. В прошлом - врач-реаниматолог. Вообще, программистами и тестировщиками становятся разные люди - на моей памяти были и китаист-японист, и аккордеонист. Бывают и врачи. А почему нет, если человек умный?