"V" значит "Дискуссия"

Привет! Хочу немного рассказать о природе договорок и о том, что я для себя сформулировал как "V-модель дискуссии".
Давно хотел что-то такое написать, а в итоге вчера сидел, у окна, курил, общался с коллегами по скайпу и моделька выкристаллизовалась в сознании.

Картинка для привлечения внимания:

Oooops, I did it again!

Ура, ура! Кэп вернулся и выходит на связь!

А давайте поговорим об ошибках?
Я тут недавно накосячил, но вроде как всё обошлось.
Потом подумал, а какой правильный алгоритм исправления косяков?
Для себя сформулировал так.

Итак, у нас случилась опа. Что делать?
КПЗ "Проблема":





1. Признать ошибку.
Не признав ошибки вы будете выглядеть как голый король, но без умного мальчика.
Отрицать очевидное глупо и нелепо. Контрпродуктивно.

2. Мотивация на решение - это я потом внизу напишу

3. Оповещение руководства. 
Вы не поверите, но у них свои планы. Они исходят из данных, которые предоставляете им вы.
Вот, представьте, что друг должен отвезти вас в аэропорт, а машина сломалась на полпути к вам. Вас не предупредил он, потому что менял колесо или что бы то ни было.
Вот вам пример несдвигаемого дедлайна. Если бы вам вовремя сказали, что машины не будет - вы бы вызвали такси и нивелировали бы последствия.
Это очень важный пункт. Не забываем. Более того. Руководство может даже помочь в решении. Нет, правда. У меня такое было.

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

5. Расследование.
Проводим первичный анализ причин косяка для того, чтобы найти тот этап/то место, с которого "что-то пошло не так". Даже "эффект домино" начинается с одной маленькой доминошки.

6. Устранение причин.
Ну, тут всё понятно. Дебаг кода/откат базы/восстановление бэкапа, письмо руководству с отчетом. Это просто надо сделать.

7. Ретроспектива.
Проводим ретроспективу. Что произошло, почему произошло, как этого избежать в дальнейшем. Опционально (и не очень конструктивно) раздача указандюлейий.

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

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

Может немного косноязычно вышло, но как-то так.

Ошибайтесь в меру, друзья.
Много ошибок это, без сомнения, плохо.
Но без ошибок нет опыта. No pain, no gain.
Кто не падал, тот не умеет подниматься.

Stay tuned!

Просто запомнить.

1. Событие является неожиданным (для эксперта)
2. Событие производит значительные последствия
3. После наступления, в ретроспективе, событие имеет рационалистическое объяснение, как если бы событие было ожидаемым.

О бедном RedMine замолвите слово.

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

Как посчитать вклад в проект?

Мальчики и девочки, мы продолжаем рубрику "просто о сложном".
Сегодня мы поговорим с вами о KPI в применении к вкладу сотрудников в проект.
Раз уж взялся капитанить, то продолжу.

Пример будет простой и наглядный.
Допустим, вы тест-менеджер и у вас в подчинении 4 человека.
Пусть это будут А, Б, В, Г:
Андрей
Борис
Вика
Галя

Вы замечательно протестировали продукт и сдали его заказчику.
Заказчик так рад, что хочет раздать всем премии. Как делить - решать вам.
Андрей упорно работал, щелкал задачки как орехи.
Борис неделю болел, но выполнил одну оооочень важную задачу.
Вика работала упорно и много задерживалась.
Что-то не получалось, но было видно, что она очень старается.
Галя работала... ну как-то средне. Вы не обращали на неё внимания.
То есть поделить просто 25%+25%+25%+25% не получится.
Ах да! И себя же надо не обделить!

Что я предлагаю делать в таких случаях:
Давайте для начал будем оценивать весь объём работ как единицу.
Ну или 100%. Лучше будет даже 100 баллов.
Далее. Каждой задачке даем "вес" в определенное количество баллов.
Так, например, тест элементов главной странички сайта - это 5 баллов.
А вот тест бэкенда - это 10 баллов.
И так далее и тому подобное, пока всё не будет посчитано.
Таким образом, все наши задачки, которые выполнялись в процессе тестирования,
составят эти самые 100 баллов.

А вот, когда мы всё оценили, то получается, что Андрей хоть и щелкал задачки,
но они были простые и общий вклад у него не больше 15 баллов.
Борис сделал хорошую задачку сразу на 10 баллов и добил маленькими до 18.
Вика со всем своим сидением на работе и тщанием не заработала более 10 баллов.
А вот Галя, которая "вроде бы работала как работала",
оказывается, сделала работы аж на 30 баллов!
Не забываем и себя любимого.
В итоге получаем:

Андрей - 15
Борис - 18
Вика - 10
Галя - 30
Тест-менеджер: 27

Что это значит?
Андрей - 15% от всех денег
Борис - 18% от всех денег
Вика - 10% от всех денег
Галя - 30% от всех денег
Тест-менеджер: 27% от всех денег

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

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

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

Метод цепных оценок простым языком.

Рассказывал молодому специалисту, решил поделиться тут.

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

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

Однако ты должен учитывать риски.
Например, один из сотрудников говорит, что ему надо на учебу и он пробудет там весь день.
То есть тестить вам придётся уже полтора дня. Ибо его часть работы расползется по оставшемуся сотруднику и тебе. Логично?
Да и ты понимаешь, что тебе спокойно не дадут погрузиться, а будут дёргать.
Значит ты будешь выполнять свою работу дольше.
То есть на тесты отведится уже два дня.
Это - оранжевый дедлайн.

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

Что значат эти цвета?
Зеленый дедлайн - это выполнение задачи в идеальных условиях.
Красный - это с учетом большинства рисков и проблем.
Оранжевый - это среднее время выполнения задачи.

В среднем оранжевый дедлайн это среднее арифметическое от красного и зеленого, умноженное на 90%.
То есть О =  (З + К)/2*0.9

Последний коэффициент я выработал эмпирическим путем.
У крепко сработавшейся команды и с нормальными процессами это может быть 75%. Середнячок 90%.
Если по итогам расчетов на ретроспективе коэффициент получился больше 100% - "что-то пошло не так" (с) и где-то у вас есть узкое место и какой-то timeleak.
Самое время пересмотреть ваши модусы.

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

Дилемма заключенного

Вынес для себя очень много интересного из данной статьи.
Суть в том, что некоторые, на первый взгляд, нелогичные поведения при взаимодействии с командой могут привести к взаимовыгодному результату.
Или как минимизировать ущерб при взаимном нарушении договоров.
Чума, вобщем. Интересно!
Как оказалось, кое-какие стратегии применял раньше неосознанно.
Где-то изобрел велосипед.
Схему Рапопорта использовал на прошлой работе. Но не очень успешно.

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

Вобщем, если почитать и вдуматься, то можно почерпнуть много интересного.

Имхо, будет особенно полезно для тех, кто работает с краудсорсными командами.

Начинаем работать с Testlink.

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

Вот здесь всё написано правильно и умным языком. Я же предлагаю простое обьяснение здесь и сейчас.

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

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