?

Log in

No account? Create an account

Entries by category: it

Мои профили в соцсетях



Краткое резюме есть здесь


А еще я написал книгу


Если у вас есть вопрос, то его можно обсудить в форуме

Ссылки на все мои слайдкасты перехали сюда

Очень люблю Талеба, особенно его последнюю книгу. Там чуть ли не каждая страница достойна отдельного бухтелова. Типа такого:

Между делом, готовясь к семинару в Microsoft, подготовил небольшое видео, где показываю, как настроить свежеустановленный MS Outlook под джедайские техники доведения дел до конца.

Кому интересно, смотрите и пользуйтесь:

Tags:

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

- Но гарантий, что там есть нефть я дать не могу.
- Гарантии оставь себе, а мне дай нефть.
(с) – фильм «Не бойся я с тобой»


Действующие лица:
  • Алексей – эффективный менеджер, получающий зарплату за спрашивание даты у одного человека и тупую ее трансляцию другому.
  • Женя – программист, обычно дающий оценку с нулевой вероятностью. В прошлом работал с нормальным менеджером, который знал, как составляются календарные графики на основе таких оценок.
  • Василий - программист, который умеет давать очень точные оценки. Он обладает аномальным вниманием к деталям и феноменальной способностью предвидеть возможные неприятности.
  • Карина - активная, местами даже гиперактивная женщина средних лет, HR-директор. Недавно в ее карьере случилось важнейшее событие. И последнее время ее состояние близко к состоянию программиста, который получил разрешение на переписку с нуля двадцатилетнего легаси приложения. К сожалению, она до сих пор путает мотивацию со стимуляцией.
  • Николай - ведущим программист на одном из проектов компании. По натуре своей достаточно застенчив.
Read more...Collapse )
Сегодня мимо меня проплыла ссылка на пост про программистскую неспособность давать оценки: «Программисты – самые оптимистичные люди на свете!». Пост оказался полон сопливого умиления программистским распиздяйством и мне таки есть, чего к нему добавить.

Добавлено тут...Collapse )
Огромное спасибо unv , благодаря которому появилась исправленная и дополненная версия таблички для анализа задач: Если файл на протух - дайте знать и я выложу его еще раз. Эта версия таблички работает с так называемыми элементами ToDo (Это когда пришедшее письмо, помечается флажком). Предыдущая версия не работает с ними. До того, как пообщался с unv мне флажок на письмах очень не нравился по одной причине: В списке задач появляются элементы, озаглавленные темой письма. В результате то, что должно быть списком задач в лучшем случае превращалось в список проблем, а то и просто свалку заголовков писем:
  • Проблема с сервером
  • FW: Помогите!!!!
  • FW: Re[2] Бага в системе
Это списком задач назвать нельзя никак, так как в этих словах не содержится ответа на простой вопрос: "Что необходимо сделать?". Что бы этого избежать, я пользовался макрухой, превращающей письма в задачки и прикладывающей к ним оригинальное письмо. Процесс обработки входящих выглядел так:
  1. Выделяем письмо
  2. Кликаем на кнопку на таскбаре (к которой подцеплена макруха)
  3. Открывается окно создание задачи, к которому уже прикреплено письмо и в названии задачи стоит "<Имя Отправителя>: ..."
  4. Вместо "..." я пишу ответ на вопрос "Что необходимо сделать?", например "Спросить у Васи вес сервера" или "Получить от Коли книжку"
  5. Сохраняю задачу
Но unv открыл мне глаза! Оказывается можно щелкнуть на флажок у входящего письма, а потом на образовавшейся задаче нажать F2, после чего заменить заголовок задачи (вместо "FW: Re[2] Бага в системе" написать "Посмотреть логи сервера"). Попробовал такой алгоритм работы, оказалось достаточно удобно. Плюс unv исправил ряд моих косметических оплошностей, за что ему наше IT-шное спасибо! Для тех, кто не в курсе что это за табличка, рекомендую ознакомиться с джедайской техникой пустого инбокса, дающей +1 к выносливости и +2 к личной производительности.

Tags:

В вопросах поощрения и наказания каждому менеджеру хочется казаться объективным, и иметь простой алгоритм принятия непростых решений. Например, кому дать больше премии? Смотрим на показатель X, умножаем на вес Y и вот она волшебная сумма! Главное потом, когда ребята придут, можно будет потыкать пальцами в цифры, и сказать: «Это не я так решил, это цифры так сказали».

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

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

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

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

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

Допустим, в день принятия решения о размере премий я получил на своем столе следующий отчет:
 
Сотрудник Число багов
Программист110
Программист26
Программист38
Программист412
Программист511
Программист67
Программист712
Программист811
Программист99
Программист1010
 
Среднестатистический программист в моей команде делает 9,6 бага в месяц. И… О, ужас! Более половины моей команды имеют степень багливости выше средней! Но не в этом суть. Если я решил материально мотивировать людей за код без багов, кого мне стоит обделить премией, имея эти цифры? Из них видно, что программисты 4 и 7 сделали в два раза больше багов, нежели их коллега Программист 2. Если я накажу программистов 4 и 7, и поощрю программиста 4, будет ли это справедливо?

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

Давайте на минутку забудем о том, что программисты пишут код и в этом коде потом кто-то ищет баги. Задачи все разные, люди еще более разные… Предположим, что эти цифры я получил в ходе очень простой игры:
  1. У каждого из ребят есть ведро
  2. В ведре насыпано 100 красных шариков, 900 белых и все это хорошо перемешано
  3. Каждый из ребят закрывает глаза, и наугад вытягивает 100 шариков
  4. Потом в выборке каждого мы считаем число красных шариков (типа багов)
Классная игра? Все в равных условиях. Вариации за счет человечности сведены к минимуму – у всех работа до обезъянности одинакова, вариации за счет каких либо иных условий так же сведены к минимуму. Если какие-либо вариации имеют место, то они происходят исключительно из-за самой системы.

Могу ли я получить точно такие же цифры, как приведены в табличке выше? Легко!

Конечно, при выборке 100 шариков из 1000 (900 белых и 100 красных) наиболее вероятным исходом будет 10 красных шариков. Но никогда нельзя рассчитывать исключительно на наиболее вероятный исход, пока у нас нет полной уверенности, что все остальные исходы «невероятны». Если вооружится экселем и биномиальным распределением, можно обнаружить, что в рассматриваемом примере такой результат как 10 красных шариков из 100 действительно наиболее вероятный, но вероятность этого исхода всего лишь 13,1%. Вероятность получить 9 красных шариков в выборке – 13%, то есть практически такая же. Поэтому нельзя сказать, что вытянувший 9 более предусмотрительный, чем тот, кто вытянул 10. Вероятность вытянуть 11 шариков равна 12%. То же не сильно отличается от наиболее вероятного исхода. И вообще в этой игре с вероятностью 94% я вытягиваю от 5 до 15 красных шариков. То есть тут нельзя с уверенностью сказать, по какой причине я это сделал? Либо я аномально везуч, либо я подглядывал, набирая шарики, либо просто так устроена работа, которую мне надо было сделать. Кстати, для результата 5-15 шариков последнее намного более вероятно, чем первые два. Вот если у меня оказался всего 2 или 20 красных шарика, то тут уже с хорошей вероятностью можно сказать, что эта вариация уже не системная. Но все равно для более точного заключения стоит понаблюдать мои результаты за несколько раундов.

Что в итоге имеем, если в игре с шариками я буду увеличивать премию тем, кто набирает меньше 10 красных и уменьшать тем, кто вытягивает больше 10, то за что же я буду поощрять и наказывать ребят? Исключительно за их везучесть, а не за их личные качества. К какому результату это приведет? Об этом лучше спросить тех, кто много рассказывает про мотивацию и все такое. У них будет масса всевозможных ответов…

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

И последнее… Игра в шарики и поиски багов – это не одно и то же, это понятно. Но тот, кто открыт новому, как правило, ищет сходства, а не различия…

Tags:

Profile

Cartmendum
cartmendum
cartmendum

Latest Month

August 2019
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow