Неконструктивные приемы коммуникаций

Люблю смотреть выступления Александра Орлова.
Рассказывает про умные вещи, складно, красиво. Шутит, держит аудиторию.
Сам смотрю и вам советую.

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

Низы не хотят, а верхи – не понятно

На Стратоплане выложили один любопытный управленческий кейс с разбором.

Памятные даты

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

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

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

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

В нашей компании заполнение тайм-шитов не будет слишком эффективным.

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

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

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

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

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

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

Закончить хотелось бы фразой из Голдрата -

"Учёт затрат - самый большой враг продуктивности!"

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

Мнение выраженное в этом сообщении является частным мнением и может не совпадать с официальной позицией компании.

Александр Белов в Киеве

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

О зефирках

Друзья, я часто слышу о зефирном тесте. Это тот эксперимент, где детей оставляют наедине с зефиркой и обещают еще одну, если первая не будет съедена за пятнадцать минут.
Красиво, эффективно, убедительно.
Скажите, а есть контр-примеры? Может быть существует альтернативное мнение, какие-то не столь популярные исследования с противоположным результатом? Или, может, подтверждающие? Что-то кроме загадочного Walter Mischel.
Лично мне, как трагические ситуации из окружающей реальности представляются забытые истории из 90-х, с обещанием сказочных прибылей согласившимся "купить акции завода сейчас" или супер-премии "когда все наладится" при задолженности по зарплате в несколько месяцев.
Как вы думаете, новый миф и заговор корпораций или особенность человеческой психологии?

На планировании

В переговорке, оккупированной под проведение планирования, стояла тяжелая атмосфера. Решение не давалось. Помимо ведущего архитектора Ивана Константиновича и его "правой руки", подающего большие надежды программиста  Василия, на мозговом штурме присутствовали:
Марк Захарович, директор департамента;
Петр Семенович, начальник отдела продаж;
Максим и Федор, продавцы-консультанты;
Зоре Ахметовна, главный бухгалтер;
Леночка, сотрудница отдела кадров;
Генадий Петрович, электрик;
Секретарша Юля (просто потому, что раз почти все тут);
и ответственный сотрудник Захарыч.
Решение не приходило. Идеи и предложения уже не сыпались как из мешка, а вяло падали на большой переговорный стол и там замирали под тяжелыми взглядами штурмующих.
С областью видимости переменной крСчетчикЗаказов все было так же не ясно, как и в начале встречи.
Шел второй час черепно-мозгового штурма.

В подражание Максу Дорофееву (cм. тэг softwarestories).

Шесть правил Глеба Жеглова

Хроник-тестировщик w-bf приводит в пример отрывок из фильма и пишет о программистах и тестировщиках.
А я бы тут говорил о заказчике и разработчике. Как вытянуть из заказчика что ему на самом деле необходимо? Как получить информацию о том что больше всего беспокоит заказчика и наладить эффективную коммуникацию? Надо усвоить работу со свидетелем...

5 уровней конфликта

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

Матрица Манштейна

Вот что писал генерал германского генерального штаба фон Манштейн:

Есть только четыре типа офицеров. 

Первый тип — это ленивые и глупые офицеры. Оставьте их, они не приносят вреда… 

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

Третий тип — трудолюбивые тупицы. Эти люди опасны и должны быть расстреливаемы на месте. Они нагружают всех совершенно ненужной работой. 

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

Спасибо PM DAY 2012

Работа с командой

В процессе одного обсуждения родилось очень меткое выражение: "Тимдилдинг".

Идеалисты против реалистов

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

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

А если и нагрузка у тестировщиков близка к 100%, то тем более на такие "мелочи" не находят времени.

Из моего опыта (касательно test case design/review): помогает peer review with checklist (шпаргалка - что именно должно быть заполнено): таким образом за тест кейс отвечают уже не один, а два человека, причем в 1ую очередь спрашивают с peer reviewer'a: почему поля и данные (четко указанные в чеклисте), пропущены.
Плюс ревьюеры могут потом рассказать, кто лучший и кто худший в этом процессе (сколько раз возвращали они тест кейсы на доделку) - и тут адресно можно помочь людям.

Проблема не в людях, а в системе.

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

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

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

Через некоторое время выясняется, что тестировщики - вьетнамцы.
И сразу появляется еще один ответ в тему:

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

Вопрос на сообразительность: как вы думаете, чей способ окажется эффективнее?
И вопрос на подумать: а вы уверены, что в вашей компании вас не считают "вьетнамцем"? =)

Группа NT-PM101-27.07.2001

Наша замечательная, на самом деле сильная группа.

Уважаемая Людмила! Ребята!
Спасибо вам большое, с вами было приятно работать. Когда придет время подписывать с вами миллионные контракты на проект, я буду знать, что работаю с по-настоящему умным "стейкхолдером". =)

Пусть ваше BCWP превышает BCWS при стабильном ACWP.

Являются ли деньги хорошим мотиватором?

Являются ли деньги хорошим мотиватором?

На этот вопрос отвечает Дэн Пинк:

Дилберт и кейсы по PMBoK

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

Процесс или результат?

Совсем недавно мы основательно препирались с шефом по поводу одной методологической мелочи. В ходе «горячей беседы» шеф спросил:

«...почему я должен потратить ДВА часа вместо часа?
что важнее – РЕЗУЛЬТАТ или ПРОЦЕСС?»

Казалось бы, ответ очевидный: конечно, результат! Кого волнует какой-то там процесс, если результат – вот он, перед тобой. Да и сам процесс, собственно, затевался именно ради результата, а не наоборот.

Но!

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

Есть мнение, что:

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

Так в десятой главе с сочным названием «Качество программного обеспечения» говорит нам SWEBOK. Во всяком случае все, кто согласен с этой формулировкой, ссылаются в первую очередь туда.
К тому же примерно о том говорят сверхпопулярные стандарты серии ISO 9000. Обратите внимание, что:

ISO 9000 – серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.

Или как объясняется чуть ниже:

Важно понимать, что соответствие стандарту ISO 9001 не гарантирует высокое качество продукции. Термин «quality management» здесь было бы правильнее переводить как «управление добротностью». Соответствие требованиям и рекомендациям этих стандартов говорит о способности предприятия:

• делать всё максимально возможное для достижения поставленных перед собой целей;
• улучшать результативность своей деятельности.

То есть, по сути, стандарты ISO 9000 выдвигают требования не к качеству конечного продукта, а к качеству ПРОЦЕССА его создания. Просто и со вкусом. И вряд ли найдется человек, который ни разу в жизни не встречал надписи «ISO 9001», например. А какие настолько же популярные стандарты на конечный продукт вы знаете? Кроме, конечно же, того самого пресловутого ГОСТа, слава которого тянется из советских времен?

Программисты, конечно же, знают обо всем этом и не устают повторять окружающим (см. «Страсти по качеству», раздел «Не плюй в колодец ISO 9000...»). Но, увы, не все верят.
Мне повезло. У меня перед глазами есть живой пример. Две команды разработчиков, у одной из которых нет процесса вообще, а вторая как-то пытается налаживать процесс. И знаете, кажется, у второй дела идут получше.

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

А я желаю вам хорошего дня и хорошего кода.

Лучшие практики инженерии создания ПО

Учебный центр Luxoft проводит очередной интересный семинар - "Лучшие практики инженерии создания ПО".

Семинар является вводным в методологию RUP - Rational Unified Process.
Рассматриваются лучшие практики, используемые в проектах по разработке программного обеспечения.
Дается введение в итеративную разработку ПО как мощное средство снижения рисков проекта.

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

Присоединяйтесь!

Вторая scrum доска

Помните, я показывал вам свою первую доску? С того времени она немого подросла, вот она:

Что изменилось? Во-первых она стала больше и исчезла колонка "Выполненно". Оказалось, что она не нужна, задачи после разработки переходят сразу в тестирование.
Во-вторых есть легенда по стикерам: желтые - обычные истории, синие - не девелоперские задачи. Например, чистое написание манов не связанное с текущим кодированием (маны-то мы и так по каждому вопросу пишем), администрирование или research. Еще есть красные, но на этом фото их нет (что хорошо). Красные - срочные, не запланированные, авральные вопросы, которые нужно быстро решать и выпускать внеочередной bug-fix.
В третьих теперь задачи на доске действительно располагаются по-приоритету (и, кстати, то, чего вы не видите это реальный приоритет, установленный настоящим product owner-ом и сложность установленная planing poker-ом).
В четвертых есть календарик на итерацию с отметками сколько дней отработано, сколько еще осталось. Это зародыш burndown. Пока мы не эстимэйтим задачи в часах и у нас еще нет разделения на user story и tasks, так что толком burndown и не построить, но все еще впереди. А пока хватает и календарика.
Ну и удобный стикер прямо на самой доске с информацией о том во сколько проходит ежедневный daily scrum. =) Теперь никто не сможет сказать, что он не знал когда и где у нас scrum. Ответ перед глазами - у доски в 9:30.

Моя первая scrum доска

Авто-фокус

Об интересной системе управления собственным списком задач пишет Алексей Рубцов.
Встречайте - Авто-фокус.

Мензоберранзан. Отчет скрам-мастера.

Начало

Среди мастеров ролевых игр, так же как и среди разработчиков, бывает так, что появляются проблемы коммуникации внутри команды. Но, если у разработчиков есть тот самый волшебный scrum, то для мастерских команд пока нет каких-то универсальных рецептов-фреймверков.
И вот, совсем недавно благодаря уважаемой Юлии Владимировне, у меня появилась возможность попробовать одну из техник методологии scrum на ролевом проекте Мензоберранзан – технику «daily scrum» или, как ее еще называют «мастерские планерки».

Адаптация

Для начала была сделана адаптация ко временным рамкам. Если у разработчиков итерация длится 2-3 недели, то тут срок всего проекта 4-5 дней. Логически было удобно представить, что один день это одна итерация. В итерацию изначально мы решили включить 4 планерки (последняя совмещенная с ретроспективой). Так же пришлось немного изменить последний из трех вопросов («Что мешает?») на «Хоз.вопросы». Это было нужно, так как мастера по-сути высший «решающий орган» на полигоне и если откинуть ответ «мешают игроки», то останется только влияние окружающей среды, погода и хоз.часть.
Так же отдельно было оговорено проведение «медленной» части планерки, что для девелоперов, как правило, очевидно.
Подробности можно посмотреть в полном scrum-манифесте для этого проекта, который был опубликован в самом начале, как основной документ.

Практика

Для начала несколько слов о технике.

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

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

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

Баги

Одной из самых серьезных проблем в отношении планерок было то, что мастера люди, а не роботы. :)

1. Некоторые были слишком эмоциональны и «растекались мысью по древу».
Само по себе это не плохо и совсем не запрещено scrum-ом. Но дело в том, что в условиях малого количества времени, когда видно, что планерка затягивается, сами мастера стараются ее сжать. И получается, что некоторые мастера не успевают дать ответы на три обязательных вопроса из-за того, что до этого было много эмоциональных отчетов.
Еще один из побочных эффектов этого заключается в том, что некоторые «стеснительные» мастера будут стараться выступать в конце, чтобы сократить свой рассказ.

2. Некоторые мастера недостаточно ответственно относились к своей очереди выступления и в свой рассказ включали только общие фразы вроде «делал все то же самое, буду делать это же». Зато вставляли множество дополнений в рассказы других мастеров с комментарием «о, я забыл что…»
Это тоже пагубно отражалось на времени, кроме того имело еще один серьезный побочный эффект. Тот, кто чаще всего говорил «о, я забыл что» посреди чужого рассказа в итоге сам не слышал остальных, так как был сосредоточен не на том, что говорит другой, а на том, что ему нужно добавить.

3. И третье это, наверное, не бага мастеров, но тоже важный момент. Очень мало внимания уделялось второму вопросу «Что будет?» (или «Что буду делать?»). Понятно, что игра развивается непредсказуемо и у многих, например, у мастера боевки, не может быть особых планов, если неизвестно будут ли вообще боевые эпизоды. Поэтому этот пункт планерки нужно обсудить. Если он не нужен, возможно, исключим его или преобразуем в нечто полезное.

Спасибо!

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

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

Я обязательно напишу о том, что из этого получится, следите за обновлениями.