Показаны сообщения с ярлыком счастье. Показать все сообщения
Показаны сообщения с ярлыком счастье. Показать все сообщения

вторник, 8 июня 2010 г.

Реальность субоптимизации

Помнится мне что-то такое еще с университетских времен. А тут посмотрел и понял конкретное применение в управлении проектами и командами в ИТ. И это точно надо "заложить" себе и тому кто прочтет.

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

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

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

Гармония важна в любом аспекте жизни. :)

вторник, 16 февраля 2010 г.

Необходимая мотивация

Уже какое-то время с небольшим перерывом волновал меня вопрос мотивации персонала. Основной мотиватор это деньги скажете вы (естесственно не конкретно Вас я имею в виду). Что тут думать - деньги! Собственно, да. Идею пирамиды Маслоу опровергнуть тяжело и деньги обеспечивают основные уровни. Но у меня не было этого рычага сначала напрямую, а затем и косвенно. Приходилось выкручиваться как получалось, но я не был долго готов, чтобы озвучить что-либо вслух (тяжело это дается, когда не можешь не просто сформулировать, а просто или сложно объяснить).
Естесственно при отсутствии материальной мотивации надо придумывать нематериальную.
Сегодня просмотрел одно видео Дена Пинка (Daniel Pink) и перед тем как я постараюсь в двух словах описать как можно сделать мне кажется его стоит послушать. Он и рассказал ту базу, которую я интуитивно попытался достичь, и на чем пытался строить свои идеи. И даже больше :)

вторник, 30 сентября 2008 г.

Счастье

Счастье для QA менеджера:
- часы отработанные сходятся с часами оплаченными;
- все работники квалифицированы и могут заниматься selfmanagement и selfeducation
- все работники заняты делом и не донимают вопросами;
- начальство и так само в курсе происходящих работ;
- заказчик удовлетворяется приходящими отчетами и согласен со ВСЕМИ часами

Счастье для работника:
никаких подвохов и доработок, отчеты писать не надо, работать много не надо, повышение зарплаты происходит на желательный размер

Счастье для заказчика:
проект идет быстрее, чем запланировано; денег платить надо меньше; всем все понятно

Счастье для организации:
все работают, деньги капают, работники больше денег не требуют

И как тут можно создать так, чтобы: все делали то, что им нравится и это совпадало с интересами организации?

З.Ы. Может немного утрировано, но просто наболело