?

Log in

No account? Create an account

Entries by category: it

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



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


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


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

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

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

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

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

Tags:

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

Одним из этапов тренинга является то, что я назваю «сессия групповой депрокрастинации», когда каждый описывает то, что он давно не может сделать, и мы при помощи нехитрых приемов пытаемся помочь каждый каждому. Что забавно, в списке прокрастинируемых дел лидируют: изучение языков (английский, немецкий, Java/Python для непрограммистов), ремонт в квартире, взаимодействие с госорганами (получение заграна, разборки с ЖЭК/ГИБДД/Налоговой). Кстати, на одном из тренингов был верх цинизма: на 15 человек оказалось лишь 3 уникальных прокрастинируемых дела (какие же люди разные…).

Многие из прокрастинируемых дел удается депрокрастинировать за одну сессию. За исключением изучения языков. И ведь действительно получается как у Севы: «Я очень хочу выучить английский/немецкий/испанский/Java/Ruby, но у меня не получается». Когда мы пробуем депрокрастинировать это дело методом волшебной феи (метод заключается в поиске первого шажочка, который можно было бы сделать за 15-20 минут, и который приблизил бы нас к достижению цели), то в качестве первого шага не редко появляется: «Выделить время».

Я уже много раз встречал эту великую задачу, являющуюся неотъемлемым первым шагом большинства дел. Часто спрашивал студентов, как человек может выделять время (на сколько мне известно, наша выделительная система заточена для выделения совсем другого), что характерно, четкого ответа никто не дал. Может, вы подскажете как человек выделяет время?

Для помощи в этих случаях я выработал лечебную формулу словоблудия (и недавно прочтенная книга Бриджит Шульте только усилила мою верю в эту формулу). Смысл в следующем, мы действительно делаем то, что хотим и не делаем того, чего не хотим. Если мы чего-то не делаем, то по той или иной причине мы этого либо перестали хотеть, либо никогда и не хотели вовсе. Чтобы скрытые причины вылезли наружу вместо фразы:

«У меня не получается сделать Х потому что Y»
Попробуйте сказать:

«За последнее время, принимал решение делать Z вместо X, потому что …»

Если быть честным самим с собой, то в ответ может вылезти интересное…

«Последнее время я принимал решение задерживаться на работе вместо того, чтобы приходить домой раньше, потому что мне не нравится приезжать домой, пока там гостят подруги жены/не спит теща/не накормлен кот»

«Последнее время я принимал решение слепо следовать заветам из аутлука вместо изучения языка программирования, потому что мне страшно оказаться замеченным за этим делом, ведь руководитель и коллеги могу заподозрить меня в некомпетентности/лени/раздолбайстве»

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

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

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


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

Добавлено тут...Collapse )
Коллеги,

не подскажите ли какого-нибудь кошерненького инструмента для помощи в проведении Code Review в MS Visual Studio 2010?

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

Tags:

Скрам и субоптимизация

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

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

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

Но есть нюанс...Collapse )

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

September 2019
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow