Девятая встреча Барнаульского PM-Community

В воскресенье прошла очередная встреча Барнаульского сообщества руководителей проектов. 

К сожалению, в программе пришлось сделать небольшие изменения и доклад про методологию XP пришлось перенести на одну из следующих встреч. Поэтому, на докладе про делегирование решили время не экономить, а провести его в виде интерактивной flipchart-сессии.

Мы впервые попробовали доклады в таком формате. Кроме того, это был первый парный доклад на наших встречах. Естественно, эксперимент мы решили поставить на себе, поэтому выступали вдвоём с Натальей Оглоблиной – одной из основателей сообщества.

Конечно же, флипчарта ни у кого под рукой не оказалось (и с собой его, как ни странно, никто не принёс), поэтому рисовали на доске, поставленной на стул, а потом быстро всё стирали, "эмулируя" перелистывание страниц. 

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

Мы определили делегирование как передачу части своих задач подчинённому с наделением его соответствующей ответственностью и полномочиями, разобрали основные  выгоды от делегирования и попытались перечислить причины, которые мешают нам делегировать. Среди них мы выделили такие очевидные вещи как нехватку времени, недоверие сотрудникам, а также "гиперответственность" – стремление выполнить все порученные задачи и "комплекс супермена" – желание сделать всё самому и, тем самым, спасти мир. Кстати, пообщавшись с аудиторией, мы пришли к выводу, что делегировать можно, в общем-то, все задачи. Вопрос только в доверии, возможностях и компетенциях человека, которому мы их делегируем.

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

В общем, получилось в меру весело, в меру холиварно и очень интерактивно, что не может не радовать. Думаю, формат парных флипчарт-сессий можно продолжить  и в будущем.

Кстати, мы с удовольствием поможем вам "прокачать" ваши навыки делегирования. В ближайшее время в Барнауле планируется несколько тренингов по этой тематике. Интересно? Пишите!

(Ссылка) Менеджер и его время, или Кому достанется обезьяна?

Подчиненные всегда стремятся переложить свою ношу на плечи начальника. Но есть способ, позволяющий руководителю расставить все по своим местам. Впервые статья “Management Time: Who's Got the Monkey?” вышла в ноябрьском выпуске HBR за 1974 год и с тех пор неоднократно перепечатывалась, став главным бестселлером журнала.

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

• время менеджера, которым распоряжается его босс, – часть временного ресурса, которая расходуется на деятельность, навязываемую начальством. Если менеджер пренебрегает этими обязанностями, его ждет наказание; 
• время, которое забирает система, – часть временного ресурса, затрачиваемая на выполнение просьб менеджеров других подразделений. Пренебрежение этой деятельностью тоже влечет за собой расплату, хотя не столь скорую и, возможно, опосредованную; 
• время, которое менеджер тратит на собственные инициативы, – часть временного ресурса, которую менеджер тратит на реализацию собственных замыслов и выполнение обязанностей, взятых им на себя добровольно. Однако некоторую долю из этого запаса съедают подчиненные – назовем это временем, которым распоряжаются подчиненные. То, что остается, – время, распределяемое по собственному усмотрению. Разумеется, невыполнение собственных замыслов не сопровождается дисциплинарными взысканиями: ни начальство, ни система не могут наказать менеджера за пренебрежение обязанностями, о которых знает лишь он сам.

Как программисты пишут часы. Опасности общих моделей

Именно так выглядят часы,
дизайн которых придумал программист

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

В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив  вебдевную молодость, выпросил недоделанный компонент "поиграться".

Пара слов о дневнике проекта

Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.

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

Как не наступать на грабли менеджеру проекта? Вопрос, на самом деле, не очевиден. Понятно, что от этого нет универсального лекарства. Первый и самый простой вариант — «это придёт с опытом». Именно поэтому, опыт — это очень ценный ресурс, потерю которого нужно минимизировать. Один из таких способов максимально сохранить опыт от прошедших проектов я активно применяю и сейчас вам его опишу. Называется он – дневник проекта.

(Ссылка) Задача без сроков не решается

Неплохой пост по планированию продуктовой разработки. Всё точно сказано.

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

Читать дальше.

Вредные советы руководителю проектов. Часть 2

В первой части "вредных советов" я объяснил, как надо правильно работать  с планами,  командой и заказчиком, чтобы успешно провалить проект. В этой части речь пойдёт о процессе разработки и тестирования.

Проектирование

Достаточно дать программисту "смутные мысли заказчика" на одном листке, чтобы через неделю ожидать готовой функциональности. Он же профессионал!

Программисты всегда лучше, чем заказчик знают, как должно работать приложение. Они же его пишут. Кстати, требования тоже придуманы только для того, чтобы мешать программистам творить. Поэтому программисты должны смело писать так, как считают правильным, не оглядываясь на всякую бюрократию, вроде ТЗ.

Вредные советы руководителю проектов

Хотите выпускать продукт низкого качества, постоянно проваливая при этом сроки? Хотите разорванных контрактов и разъярённых заказчиков? Хотите, чтобы вас ненавидела ваша команда? Тогда этот пост для вас!

План и сроки

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

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

Про вред молчания

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

Лично мне как руководителю много неудобств приносят люди, которые чем-то недовольны, но молча сидят и ждут. Молча ждут, пока им поднимут зарплату. Молча занимаются неинтересной работой в надежде, что когда-нибудь я это замечу и осчастливлю новым проектом. Молча мёрзнут под кондиционером и уходят на больничный, так и не попросив его выключить.

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

Дальше текст немного в «чёрном» стиле. Я надеюсь, вас не смутит обращение на «ты», поскольку оно лучше передаёт эмоциональную составляющую и смысл статьи.

(Ссылка) Scrum-доска и образовательный процесс

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

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

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

Очень похоже на работу менеджера, не так ли? 

Когда все мои моральные уговорки перестали работать, я придумал что наверное нужно бы домашнее задание как-нибудь визуализировать. Или иначе говоря, сделать визуально-понятным объем предстоящей работы. А так же представить инструмент адекватной оценки выполнения домашнего задания, которому доверяет как ученик так и учитель."

Продолжение - здесь: http://ob3r0n.livejournal.com/442289.html