February 2010 Blog Posts

Планирование - один из способов мотивации

28 February 2010 |

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

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

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

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

Статистика – не обманет

25 February 2010 |

Существует распространенное мнение что статистика – это ложь, некоторое пренебрежительно отношение к ней… Проблема не в статистике, а в людях, помните “Цифры не лгут. Лгут люди.”. За последние 10 лет люди не просто перестали анализировать данные, сопоставлять, делать прогнозы, создается впечатления, большинство людей потеряло саму способность думать. Народ начинает жить на рефлексах, пусть на приобретенных, но на рефлексах, выполняя действия и приводя “суждения” даже не задумываясь, как животные.

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

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

RussiaLifeByTime

Есть желающие откинуть копыта до 35 лет? Как же раньше ведь так было хорошо, экологически чистые продукты, свежий воздух, единение с природой, а медики жить не мешают, и от от прогресса одно беспокойство.

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

Отзыв Автомобилей (Мнения)

21 February 2010 |

История с отзывом автомобилей Toyota – благодатная тема для разговора, о машинах, возможных поломках, политики и чем угодно…  В связи с тем что тема регулярно возникает в offline, есть мнение поделиться ссылкой на статью Кивино гнездо: Обратная сторона педали, даёт примеры и взгляд с различных сторон, любопытно почитать.

Comments Feed For This Blog

17 February 2010 |

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

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

Для меня оказалось проще написать отдельный сервис для решения данной конкретной задачи, если кому надо пользуйтесь RSS 2.0 Comments, та же ссылка добавлена в отображаемый список доступных каналов.

Microsoft Application Architecture Guide, 2nd Edition

17 February 2010 |

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

Как дожить до 100 лет

14 February 2010 |

Для тех кто живет в Москве, учитывая экологию и стиль жизни, дожить до 100 лет не грозит. Людям свойственно интересоваться тем, что притягательно, но недоступно, поэтому так популярны хроники светской жизни, биографии и истории из жизни “успешных” людей. Тем кто не силен в английском перед просмотром рекомендуется активировать субтитры на русском языке, в настройках плеера или ссылку.

(Дэн Бютнер  Как дожить до 100 лет   Video on TED.com)

А Чё ЭтА Вы Тут Делаете?

14 February 2010 |

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

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

Итак ЗАЧЕМ Вам нужен учет времени разработчика?

  • Потому что разработчики вместо того чтобы работать сидят в интернете/спят/играют…
    Особенность работы разработчика – трудность, вплоть до невозможности эффективно оценить результат работы, потому что результат работы разработчика это исходный код. Вы думаете, что если разработчики будут 8 часов в день сидеть с открытым редактором кода и писать код, то они сделают больше работы? Гы, гы… Если разработчики на работе не занимаются разработкой, то у Вас проблемы, серьезные проблемы, вот только учет времени сотрудника здесь не поможет, прекратите страдать фигнёй, срочно ищите причину, почему не работают ваши разработчики:
    • может это вам только кажется что они не работают?
    • хватает ли им денег на еду, ой вы забыли что им надо платить зарплату?
    • спросите, может быть они не знают что за продукт разрабатывается, или если из требований выкинуть ненормативную лексику и слова “надо, быстро” больше ничего не останется?
    • а какие штрафы за каждый обнаруженный в коде баг или за несобирающийся билд?
    • вы еще полгода назад были командиром роты, знаете как управлять и все делаете правильно?
    • вы не знаете кто такой менеджер проекта и зачем он нужен?
    • в вашей команде очень квалифицированные разработчики, почти у всех высшее образование, а самые лучше совсем недавно закончили профильный институт?
    • вы пробовали спрашивать разработчиков, почему они не работают, вдруг они знают ответ на этот вопрос?
  • Не могу понять почему на разработку такой ерунды уходит столько времени…
    Пример, почему на приложение текстовый редактор, ну типа Word, у которого всего то функциональности печать и удалять буковки, надо тратить больше месяца? А почему вы решили что знаете сколько времени это должно занимать? – вам сказал ваш знакомый - вы сам отличный разработчик и все прекрасно знаете – это же очевидно. Грустно, но что поделать, посекундное расписание того что делает разработчик вам не поможет, вам вообще скорее всего мало что поможет…
  • Заказчик/самый главный постоянно спрашивает сколько на какую функциональность ушло времени и почему
    Скорее всего вы менеджер/руководитель. Как называется роль - кто должен следить за  планом, ходом проекта и быть ответственным/отчитываться за это? Основная задача разработчика – проектирование и написание кода, неправда ли? Кто и как оценивает, сколько займет реализация той или иной функциональности? Верите ли вы этим оценкам, с какой погрешностью, верит ли заказчик/учредитель этим оценкам, требуются ли доказательства “честное слово”, “зуб даю”…? Выходят ли реальные сроки за оцениваемые, насколько? Кто определяет, отслеживает приоритетность задач и их последовательность выполнения? Нужно ли разработчику думать о том какие будут задачи после текущей, и если да то зачем? Зачем заказчику разработчику знать сколько на что ушло времени, он хочет понять почему – тогда ему надо быть менеджером, он не доволен сроками – тогда хронометраж работы разработчиков тут не причем. Вопросы можно продолжать, оспаривать можно что угодно, но работа менеджера решать проблемы с заказчиками/учредителями и создавать условия чтобы ничего не мешало разработчикам работать, а не пытаться увеличить набор обязанностей разработчиков для решения профессиональных задач.
  • Интересно знать, какое время тратиться на работу, какое на коммуникации, какое на исправление ошибок…, возможно все это позволит увеличить производительность
    Вы занимаетесь коммерческим проектом? Ваша диссертация называется: “Революционная методология разработки ПО имени Васи Пупкина”? Вы верите что от этой статистики будет пользе больше чем затрат на ее сбор? Итого: перестаньте заниматься личными делами на работе.
  • Разработчики не умеют следить за собственным временем, не ценят его и как следствие не могут что либо адекватно оценить, хочется выработать в них этот навык
    Действительно навыки/практики Time Management-а вещь полезная, и человек “чувствующий время” более эффективный работник чем такой же человек без надлежащих навыков. А нет ли других эффективных методик повысить эти навыки разработчиков, почему вы выбрали именно такой способ, есть мнение что теории + 1-2 недель работы достаточно, о чем речь?
  • Публичная ежедневная новостная лента о каждом разработчике, мотивирует тех кто отчитывается (тщеславие великий грех) и позволяет сплотить коллектив взывая сопричастность, знание чем кто занимается даст возможность получить помощь от других разработчиков
    Вы последователь Agile, может быть знакомы со SCRUM… что там про ежедневные встречи, вы это называете учетом/контролем рабочего времени, или решили усовершенствовать?

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


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

Роль разработчика во всём том что касается времени обычно сводится к следующему (тонкости и вариации зависят от методологии, но в среднем по больнице так):

  • Определение какие работы необходимы для реализации какого либо требования
  • Оценка времени на выполнение работ или/и экспертная оценка времени на реализацию требования (есть разные мнения на тот счет какая оценка получается точнее, логика подсказывает что первая, практика что вторая, в данном контексте неважно)
  • Информирование о ходе/прогрессе выполнения работ
    • Завершена работа/не завершена
    • Сколько осталось до завершения работы (если эта оценка изменилась от предыдущего значения)
  • Реорганизация набора работ, если со временем стало понятно необходимость в дополнительных работах и/или не нужности существующих

Вот это тот МАКСИМУМ который может/должен делать разработчик в контексте “сроков/времени”.

P.S. Знаете почему исчез рабовладельческий строй – потому что был экономически не эффективен, по сравнению с феодальным. А почему феодальный… Есть основания полагать что учет времени разработчиков/сотрудников с трудно контролируемым результатом – экономически не эффективный способ для оценки их работы.

Письмо разработчика…

13 February 2010 |

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

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

Вас не поставили кажется в копию. Но тем не менее почитать ответ будет
поучительно. Это если бы я пришел к бухгалтеру и начал говорить как
оформлять проводки... Или пытаться объяснить папуасу почему стрела
выпущенная из лука не может долететь до солнца:
П: Я возьму большой лук сильно натяну и стрела попадет прямо в солнце.
Ч: Солнце очень далеко, так не получиться...
П: Э Мы сильный и смелый охотник, мы убивать зебру, мы хорошо стрелять
из лука, мы его сильно натянуть и он долетит
Ч: Даже если стрела долетит до солнца то она сгорит не успев до него долететь
П: Вот, ты обманывать, сначала говорить что не долетит, теперь что
сгореть, а стрела из метала будет, в соседнем племени охотник ХЫ
показывал такую... Слушай что скажу, берем хороший лук, сильно
натягиваем, металлическая стрела и попадем прямо в солнце... только
прицелиться хорошо. Скажи из важного я ничего не забыл?
Ч: Да ... ... ... стреляйте на здоровье.

На это письмо ответить не могу, не знаю чего отвечать.

Панорамы, уже рядом…

05 February 2010 |

 

Знал что существуют сервисы предоставляющие панорамные снимки улиц города, но не придавал особенного значения. Случайно посмотрел mappi.ru, любопытно, удивило что даже самые мелкие улицы показаны. Трудно сказать насколько полезен будет сервис на практике… может быть и полезен. Пример.