Software development reality

Все уже видели много раз картинку про project management и качели. Но это что-то новенькое и котэ присутствует :) Взял отсюда взял.

Лидер vs. Менеджер

Чем отличаются лидеры от менеджеров? Лидеры вводят перемены. Там, где можно обойтись без введения перемен, достаточно менеджмента.
Основное различие между менеджерами и лидерами лежит в их глубинных представлениях о хаосе и порядке. Лидеры легко мирятся с недостатком упорядоченности. Менеджеры, напротив, стремятся к стабильности и контролю.

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

(цитата Уоррен Беннис)

Дольше всего, когда сомневаешься

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

"Не баксом единым"

Уже как-то постил видео Дена Пинка. Вот попалось еще одно его выступление очень похожее, но с некоторыми дополнениями.



А также наглядная анимированная интерпретация




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

А лучше всего позвольте команде ощущение, что это ИХ проект. Их собственный, и они не просто могут влиять на его развитие, они определяют его развитие, от их решений зависит их детище. Со своей собственностью люди чаще и обходятся по другому, совсем не так, как просто к работе.

Совет, который мне пришел на утро после QAConf 1.0

Вчера после своего выступления на QAConf разговаривали с одним молодым человеком, Test Team Lead'ом о том, можно ли использовать бёрндаун отмечая не задачи по сложности, а по количеству.
Пришли к выводу, что можно, но будет виден только прогресс, который нельзя будет хоть с какой-то достоверной точностью предвидеть. Но в любом случае он сможет помочь.

Мы к сожалению не обменялись контактами, и я решил воспользоваться тем, что мои посты отображаются на сайте нашего QAClub.

А как выглядит твой берн даун?

Ковырялся с тем как наш берндаун составляется. Он автоматом и натолкнулся на вот такую статью http://www.scrumdesk.com/is-it-your-burn-down-chart/.

Она очень систематизирует знания о том, как интерпретировать бёрндаун и советы, что с ним делать. Использовал ее для своего начала разговора на QAConf 1.0. Перевод вольный

QAConf 1.0. Анонс

17 сентября буду с небольшим докладком на тему использования и воспринимания тестировщиками Burndown'ов на QAConf.

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

Yahoos filling up the Burn down chart

Про политику и комерцию

Компании занимаются политикой в двух случаях

1. или плохо занимаются комерцией и при этом занимаются политическими взаимоотношениями с клиентом 
2. или настолько крупные, что политика государства и/или мира имеет для них очень серьезное значение

Если ко второму ваша компания не относится, то не надо скатываться к  чистому первому варианту

P.S из воспоминаний

Про ответственность

Я вот на небольшую заметку об ответственности на it4business. Острый в моем случае вопрос и не могу его обойти.

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

Заметка о процессах и взаимоотношениях

Что не писал я долго. И решил вот разродиться статьей на тему процессов и взаимоотношений. Версия 5ая, лаконичная:

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

Почему мы не делаем работу на работе?

Пересматривал выступление Джейсона Фрида "Почему мы не делаем работу на работе" (Jason Fried Why Work Doesn't Happen at Work). Интересные результаты. 





Но вот при разработке программного продукта необходимо очень много командной работы. Когда действительно необходимо постоянное взаимодействие между людьми. И отвлекаться это нормально.
Хотя если надо написать тест дизайн или просто покрыть тестами функционал. Разобрать требования заказчика и проанализировать их. Проанализировать состояние проекта и написать отчет.... То тут явно хочется повесить видимую не только тебе табличку "Не беспокоить" на видимую не только тобой дверь (open space).

Overmeetinging

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

Допустим, несколько дней до релиза. И все, естесственно, не успевают. Не успевают работать в том же расслабленном режиме, что и в середине или начале итерации. И помимо ежедневных утренних стенд-ап митингов еще через несколько часов мы тоже проводим митинг. Просто чтобы более оперативно получать информацию и координировать ее. Правильно. Хорошо. Оперативно. Но людей зачем отрывать от работы, если мы хотим чтобы все было оперативно? Почему нельзя самому узнать необходивую информацию непосредственно, вместо того чтобы вырывать всех из контекста всех. Пусть они делают свою работу. Кто-то вот-вот что-то закончит, а кто-то только начал какой-то кусок работы. А информация вся будет у вас и так, и так. И анализировать ее и принимать решения можно в обоих случаях. Только второй получается "дешевле" и "безопаснее".

Следите за своими сроками

Подсмотрел у cartmendum'a тут. И не смог не перепостить :)

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

Тест лидер и проектный менеджер?

На самом деле я тест лид. И младший product owner и иногда не младший тоже. И менеджер команды (проекта). И просто automated QA Engineer. И в то же время все эти люди не я, и я не все эти люди, уж тем более одновременно.

Да бывает так. И не важно как кто к этому относится. Я понимаю почему так получается. И принимаю это.
Главное, что нужно научится все это разделять во времени. Но еще важнее не растерять все полезные качества каждого при этом: умение смотреть на картину в целом и видеть детали; думать о том как успеть в сроки и сделать все с достойным качеством; критиковать  все что делают и не критиковать работу людей; оптимистично смотреть на то, что перед самым релизом, и писсимистично в процессе.

Вспомню еще что - допишу :)

Быстро, не значит плохо

Вчерашняя встреча PM Zone с Томом Альберсом вдохновила меня на самоанализ и как следствие ряд мыслей.

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

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

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

P.S. Вот помнится на Agileee двое ребят очень забавно рассказывали о таком подходе. Жаль Видео нет

The sword and Other Tales

Итеративный подход 2

Как всегда во время еды во рту нарушается кислотно-щелочной баланс. Может он и повлиял на зарождение у меня одной мысли именно в этот момент.
Но для начала почему я к ней пришел и на чем основывался:

• есть такое понятие "окно срочности". Я слышал о таком и раньше из психологии. Но понятно для менеджеров описано у Орлова на его happy-pm.ru. Cуть: человек начинает работать над чем-то усерднее и ставит приоритеты выше, если это что-то попадает в это самое окно.
• процесс по которому сейчас работает команда похож на то, что можно назвать Event Driven Development. Релиз обычно раз в месяц, но может и полтора. Т.е. 5-6-7 недель. Но это не правило, а скорее статистическое среднее. Такие итерации обусловлены это тем, что система уже оченьбольшая. Очень-очень большая. Каждая докручиваемая фича как дополнительный отсек на авианосце, котрый надо встроить по всей вертикали. И чтобы сынтегрировать такое необходимо немалое количество времени. Вот и получается что зависим не от сроков, а от объемов, а сроки большие. Изредка ряд мелких изменений может занимать и пару недель. Но окно срочности у людей обычно горааздо меньше месяца-полутора. Неделя в лучшем слуае. И само собой сложностей по ходу возникает много
• малыми итерациями, которые все советуют при использовании scrum мы позволяем команде работать в одном ритме и находится в постоянном тонусе. Естесственно, если все расчитано правильно и мы делаем работу, а не совершаем подвиги каждую итерацию.

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

Жду пока мы это внедрим в ближайшем будущем и на опыте будет видно. Потом отдельно напишу

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

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

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

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

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

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

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

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

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

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

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

Как мотивировать наших людей

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

А лучше всего вести нашего человека в обозримое светлое будущее, с морковкой внутри и стимулом (тем самым) сзади. Человек всегда должен быть чем-то недоволен немного, в лени люди теряют форму

"Лучше давайте побыстрее закончим"

Последнее время я очень часто слышу эту фразу: "Давайте лучше сделаем это побыстрее".
Да, все хотят успеть сделать вовремя, или как можно быстрее, если это самое "вовремя" прошло.
Причины? Различные. В моем конкретном случае я все отношу к различным "окнам бессрочности" (вот тут прочитал) всех членов команды.

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

Если все же хочется это получить поскорее, то придется поступиться остальными углами треугольника менеджмента проектов. А QA помнят, что углов в треугольнике 4: время, ресурсы, деньги и качество :)