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

"Все мое, мое!"

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

Мотивация собственников и эгоистов.
Необходимо заставить человека думать, что работа, которую он делает относится непосредственно к нему, это его.
Например, не сказать человеку что необходимо сделать, а объяснить что хочется получить (не конечный ожидаемый результат, а цель), зачем это необходимо и какие могут быть последствия. А главное делегировать ему ответственность за то, что он будет делать. И это не означает только обязанности, но и права и полномочия, т.е. всю полноту власти, необходимую для выполнения порученной работы. Естественно, только в том случае, если мы уверены, что человек сможет этим воспользоваться ;)
По-моему это нормально и очевидно. Важно сделать это не со словами "не мог бы ты" или "я тебя попросил бы". А "я отдам тебе", "твоя часть .... это нужно затем-то и потому-то". Это будет его(ее).

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

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

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

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

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

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

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