• Схема разрешения проблемы

    Posted on January 31st, 2010 Александр Орлов 1 comment

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

    Но потратить два часа на обучение может не всякий. Для тех, кто не может – специальная простая схема разрешения проблем:

    Взято отсюда.

    Fun
  • Путь наверх по руинам

    Posted on January 29th, 2010 Александр Орлов 8 comments

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

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

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

    У нас, говорит, Сань, есть вице-президент, сделавший стремительную карьеру. Мы потом решили посмотреть, что случилось с проектами, которые он вел. Все проекты провалились.

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

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

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

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

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

  • Между дедлайном и хулиганами: разбор кейса

    Posted on January 29th, 2010 Александр Орлов 8 comments

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

    «Он понимал, что дело не в законодательстве и даже не в безопасности (она лишь повод), а в том, что Тане не хочется работать по неудобному графику.» – на месте Олега я бы тут подумал чуть глубже. «А почему Тане не хочется работать по такому графику?» Вероятно потому, что девушка не хочет, чтобы хулиганы на пустыре таки добились как-нибудь своей цели. То есть, за себя боязно.

    Когда за себя боязно, желание думать о работе как-то притупляется. Поэтому даже если Таню заставить административно-приказными способами приходить в 13 и уходить в 22, работать она все равно будет плохо. Голова не о том. А тут еще менеджер давит приказами, что автоматически покажет человеку, что менеджер – идиот и не заботится о сотрудниках.

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

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

    Да, и извиниться перед Таней не помешает, раз уж довел девушку до того, что он пошла в HR письма писать.

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

    Люди шепчутся в курилке зачастую из-за того, что не понимают решения начальства. «Блин, все было нормально, работали как люди, а теперь зачем-то надо сидеть до ночи? Какого хрена? Почему чикагцы не могут прийти на работу к 4 утра?..» Отсюда и опоздания и все остальное.

    Так это, надо объяснять решения. И команде, и один на один. «Мы работаем на то, чтобы перетащить позиции разработчиков в Киев. Мы зарабатываем деньги.» и пр., и пр. – с каждым человеком в зависимости от того, что его лично мотивирует.

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

  • Happy PM в Харькове: 28-30 января

    Posted on January 28th, 2010 Александр Орлов No comments

    Следующие три дня буду в Харькове с комическими куплетами:

    28 января, встреча сообщества IT Talk. Буду рассказывать про Visibility.

    29 января, встреча сообщества QA Club. Буду рассказывать про карьеру в менеджеры из тестеров.

    30 января, тренинг “Карьера менеджера в ИТ”.

    Если кто-то находится в Харькове – приходите на любое мероприятие, буду рад увидеться.

  • Партизанский менеджмент

    Posted on January 28th, 2010 Александр Орлов No comments

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

    (Хотя способы менеджеров-партизанов обсуждаются уже давно – даже мы там отличились на первом SEF‘е.)

    Fun
  • Культуры программных проектов: часть 10

    Posted on January 28th, 2010 Александр Орлов No comments

    (все выложенные на текущий момент части – здесь)

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

    На одной конференции я встретил тимлида. Его команда использовала RUP и его унифицированный язык моделирования UML. Они использовали коллаборационные диаграмы UML как часть своей работы над дизайном, но заспорили о том, не являются ли последовательные UML диграмы лучше. Они беспокоились, правильный ли путь они выбрали, и спросили меня, не надо ли им переключиться.

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

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

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

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

    Многие методологи очень восприимчивы к таким дырам, и, когда им их показывают, они стараются заполнить их в следующих версиях книг с правилами. В результате предписанные правила становятся ещё более сложными, а методологии со временем становятся более догматичными. Разумеется, это делает методологии менее субъективными, что может помочь разрешить некоторые споры, но создаёт опасность того, что методология станет менее гибкой и слишком громоздкой для применения. Кроме того, невозможно заткнуть все дыры, а потому, стремление к совершенству просто бесконечно.

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

    Продолжение следует …

  • Тест-дизайн от А до Я: 5 февраля, Москва

    Posted on January 27th, 2010 Александр Орлов 2 comments

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

    Алексей Баранцев, тренинг “Тестирование от А до Я”. 5 февраля. Москва

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

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

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

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

    1. Построение карты функций приложения и проектирование тестов по этой карте.
    2. Разделение областей данных на поддомены (классы эквивалентности), эвристики выбора представителей.
    3. Способы проектирования тестов для цепочек функций.
    4. Проектирование тестов на основе вариантов использования.
    5. Проектирование тестов на основе гипотез об ошибках.
    6. Подход к тестированию, основанный на анализе рисков.
    7. Комбинирование различных эвристик.
    8*. Особенности проектирования тестов для регрессионного тестирования.
    9*. Особенности проектирования тестов для автоматизации их выполнения.
    10*. Особенности проектирования тестов различных уровней (модульные, интеграционные, системные).

    Место проведения: Москва
    Дата: 5 февраля
    Время тренинга: 10:00 – 18:00

    Стоимость участия в тренинге: 4500 рублей.

    Бонусы!!!

    При одновременной регистрации и оплате двух участников (или одного участника на два тренинга) скидка 10%, трех — 15%.

    Чтобы записаться на тренинг, необходимо написать письмо по адресу trainings@software-testing.ru, в письме укажите ФИО и название тренинга.

    Будем рады видеть вас среди участников!!!

  • Цитата недели (Джоэл Спольски)

    Posted on January 26th, 2010 Александр Орлов No comments

    Умение ясно писать на технические темы — это то, что отличает руководителя от невнятно бормочущего программиста.

  • Культуры программных проектов: часть 9

    Posted on January 25th, 2010 Александр Орлов No comments

    (все выложенные на текущий момент части – здесь)

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

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

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

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

    Наибольшей проблемой на мой взгляд было то, что все знали методологию, но очень немногие её понимали. В частности, менеджеры проектов так фокусировались на соблюдении буквы закона, что не могли посмотреть на результаты со стороны. Без чёткой перспективы и более широкой картины они даже не могли спросить, есть ли вообще смысл работать таким образом?

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

    Большая американская компания – назовём её ИнтерСофт – купила задокументированную методологию у компании, которую назовём МетодВаре. МетодВаре была сертифицирована третьим уровнем СММ.

    Компания ИнтерСофт была впечатлена этим уровнем сертификации; она узаконила методологию компании МетодВаре. Меня это малость передёрнуло. Я объяснил, что СММ нацелена на то, чтобы показать зрелость процессов в организации (то есть в МетодВаре), а не зрелость методологии, которую они продают.

    SEI CMM определяет пять уровней зрелости. Первый – это вцелом неконтролируемый хаос. Второй – это когда некоторый контроль существует и применяется на некоторых проектах. На третьем уровне методология детально задокументирована и является обязательной во всей организации.

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

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

    Продолжение следует …

  • Две говорящие головы на хабре

    Posted on January 22nd, 2010 Александр Орлов 4 comments

    Свершилось историческое событие! Мы со Славой Панкратовым оформились в стартап “Две говорящие головы” и теперь ведем блог на хабре. Ура!

    Опубликован первый топик “Хабр-здравствуйте”. Все хабра-юзеры приглашаются поплюсовать-поминусовать. (Тех, кто будет минусовать, мы, конечно, потом вычислим. :) ) )