Oooops, I did it again!

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

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

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





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

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

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

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

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

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

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

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

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

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

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

Stay tuned!

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

Мальчики и девочки, мы продолжаем рубрику "просто о сложном".
Сегодня мы поговорим с вами о 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.
Самое время пересмотреть ваши модусы.

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