Эффект Приближения к Цели

Когда свои мысли еще не оформились для изложения в блоге не грех и написать об интересностях, прочитанных на других ресурсах. Так в начале декабря на Software People появилась интересная статья об "Эффекте Приближения к Цели". Фабула этой статьи в следующем: не только реальный прогресс, но и даже его иллюзия повышают мотивацию. С точки зрения people management, а так же в контексте построения отношений с заказчиком это дает интересную пищу для размышлений. Правда, как и любой фокус, этим инструментом необходимо пользоваться осторожно и не злоупотреблять, иначе это превратится в профанацию. Так что кладем на полочку в нашей голове с пометкой "интересно, попробую как-нибудь" :)

Моя Шизофрения

Всем привет!

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

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

1. Собственно, Менеджер проекта (планирование, отчетность)
2. Бизнес Аналитик
3. Системный Аналитик
4. Лидер (визионер)
5. Владелец проекта (если у нас scrum-scrum)
6. People Manager (карьера членов команды, развитие, обучение, зарплаты...)
   

Довольно много разных ролей, не правда-ли? И, что характерно, активности, а самое главное интересы в этих ролях далеко не идеально совмещаются. Одно из наиболее явных противоречий, которое сильнее всего проявляется - это совмещение двух следующих зон ответственности:
1. Отстаивание интересов заказчика
2. Отстаивание интересов команды

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

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

Вы, Project Manager, находитесь на этой позиции, что бы отстаивать интересы каждого из участников проекта, так как сами они не хотят или не могут этим заниматься. И, естественно, если кто-то почувствует свои интересы ущемленными, то мучительно больно будет именно Вам!

Вот и получается, что менеджерам проектов постоянно приходится вести незримый бой по отстаиванию интересов всех участников проекта прямо в своей голове. Да на таком уровне, что мистер Фикс из старого мультфильма "За 80 дней вокруг света", ведущий диалоги сам с собой выглядит абсолютно здоровым человеком.

Что с этим делать? Хмм...думаю, что об этом будет рассказ во второй части этой статьи. И я лучше это обдумаю и интрига будет напряженнее :)

Думай о хорошем

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

«Муха, как и пчела, очень любит мед. Но она не может удержаться и пролететь мимо какашек. Пожалуйста, думайте о хорошем...»

Анонс следующей встречи Agile-Питер!

Итак, определена дата проведения следующей встречи Agile-сообщества Санкт-Петербурга.
Тема новой встречи — «Работа с заказчиком и управление требованиями».
Обсудим, как быть с изменениями и жёсткими ТЗ, как строить отношения с заказчиком, что делать, а также попробуем вместе найти ответы на ваши вопросы.
Модерирует дискуссию консультант ScrumTrek — Алексей Корсун.

Участие бесплатное; количество мест ограничено.

Более подробный анонс и регистрация на Хабре: http://habrahabr.ru/blogs/agile/109210/

Где живут менеджеры

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

"Менеджеры живут на информационных потоках..."

Офигенно емко, выпукло, красиво и на 1000000% верно... здесь мы и живем, и все есть иллюзия, пока ты не поймешь этого... с пониманием этой простой и ясной мысли становятся не нужны Стивен Кови и другие консультанты, да и сам Александр Орлов уже не так необходим :) Просто с пониманием и принятием этого тезиса меняется система ценностей, меняется мотивация и поведение во всем...

Встречи AgileRussia.SPB

Свершилось историческое событие - в наших северных болотах "возобновились" (а учитывая, что перерыв был столь долог, что о них мало кто помнит) встречи сообщества AgileRussia! Наконец-то, наконец-то в нашу гавань зашли корабли гибкости и встали на якорь рядом с bootиком Piter the First!
Итак, в четверг, 18го ноября, в 19.00 по Ленинградскому времени Алексей Корсун, Михаил Карпов и Татьяна Васильева (пардон, лично знаком только с Алексеем :( ) собрали довольно значительную компанию людей (около 15 человек), которым интересен Agile. На повестке дня стояло два вопроса:
- "Распределенный Agile"
- "Автоматизация сборки и тестирования!"
Встреча проходила в формате свободной дискуссии, которую стимулировал и поддерживал Арексей Корсун. Сразу накидали достаточно много вопросов как на одну так и на другую тему - причем весьма разнообразных и интересных. Все это оставило у меня массу положительных эмоций, ведь это просто суперски, когда ты обсуждаешь интересную тебе тему в компании интересных, конструктивно настроенных людей. Приятным сюрпризом было встретить знакомого, которого не видел много (по-настоящему много) лет и законнектиться с ним через мойкруг. Увы, дела призвали меня и я вынужден был свалить по-английски не дождавшись даже пиццы, так что часть информации пришлось затем доставать из организаторов :)
Так вот! Засекреченный источник из узкого круга посвященных сообщил, что следующая встреча состоится через месяц (ориентировочно 18-го декабря) и на ней мы будем говорить о работе с требованиями! И это не может не радовать меня, как человека, 50% времени занимающегося именно этим!

Надеюсь, что со следующей встречи у нас будет полноценный репортаж со всякими интересностями! Всем удачи!

Оценки в Fixed-Price контрактах

Привет!

В последнее время мне все чаще приходится выполнять SWAGи для множества проектов, находящихся на различных стадиях (чаще всего на pre-sale). И основная проблема в том, что каким бы ни был контракт: Time-Material или Fixed-Price заказчик обычно требует определить бюджет проекта. Это, в принципе, разумно, так как без предварительных данных о бюджете менеджер на стороне заказчика обычно просто не в состоянии продвинуть проект (даже если он сам распоряжается деньгами).

В дебрях рунета наткнулся на небольшую статью об оценках затрат в Fixed-Price проектах:

http://www.enter-agile.com/2010/10/fixed-price.html?spref=fb. Статья несет в себе одну единственную полезную вещь, о которой стоит помнить планируя ЛЮБОЙ проект независимо от типа контракта. Мысль простая и разумная:

Оценивайте не модули (реализацию) а функциональность (требования).

Это действительно важно и крайне полезно, так как позволяет "играть" с содержанием(scope) проекта а так же очевиднее позволяет показать заказчику "тяжесть" каждой фичи. Хотя, надо сказать, бывают и другие ситуации:

1. Бывает необходимость разделять виды деятельности (например, разработка и тестирование) так как они будут выполняться различными субподрядчиками или финансироваться из различных бюджетов.

2. Зачастую бывает проще напрячь фантазию и разработать план, состоящий из "модульных" блоков, в составе которых делать глубокую декомпозицию до задач типа "разработать класс A" весом не более 8-16 часов, потому что только так можно показать ожидаемую продолжительность проекта заказчику, который не готов работать по Agile. Главное - даже не пытаться использовать этот план в дальнейшем! :)

Всем удачи! Точных вам оценок!